doc: Add RFC documents

1 files changed, 3195 insertions, 0 deletions

diff --git a/doc/rfc/rfc4594.txt b/doc/rfc/rfc4594.txt
new file mode 100644
index 0000000..135cebf
--- /dev/null
+++ b/doc/rfc/rfc4594.txt
@@ -0,0 +1,3195 @@
+
+
+
+
+
+
+Network Working Group                                         J. Babiarz
+Request for Comments: 4594                                       K. Chan
+Category: Informational                                  Nortel Networks
+                                                                F. Baker
+                                                           Cisco Systems
+                                                             August 2006
+
+
+         Configuration Guidelines for DiffServ Service Classes
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes service classes configured with Diffserv and
+   recommends how they can be used and how to construct them using
+   Differentiated Services Code Points (DSCPs), traffic conditioners,
+   Per-Hop Behaviors (PHBs), 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Babiarz, et al.              Informational                      [Page 1]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Requirements Notation ......................................4
+      1.2. Expected Use in the Network ................................4
+      1.3. Service Class Definition ...................................5
+      1.4. Key Differentiated Services Concepts .......................5
+           1.4.1. Queuing .............................................6
+                  1.4.1.1. Priority Queuing ...........................6
+                  1.4.1.2. Rate Queuing ...............................6
+           1.4.2. Active Queue Management .............................7
+           1.4.3. Traffic Conditioning ................................7
+           1.4.4. Differentiated Services Code Point (DSCP) ...........8
+           1.4.5. Per-Hop Behavior (PHB) ..............................8
+      1.5. Key Service Concepts .......................................8
+           1.5.1. Default Forwarding (DF) .............................9
+           1.5.2. Assured Forwarding (AF) .............................9
+           1.5.3. Expedited Forwarding (EF) ..........................10
+           1.5.4. Class Selector (CS) ................................10
+           1.5.5. Admission Control ..................................11
+   2. Service Differentiation ........................................11
+      2.1. Service Classes ...........................................12
+      2.2. Categorization of User Service Classes ....................13
+      2.3. Service Class Characteristics .............................16
+      2.4. Deployment Scenarios ......................................21
+           2.4.1. Example 1 ..........................................21
+           2.4.2. Example 2 ..........................................23
+           2.4.3. Example 3 ..........................................25
+   3. Network Control Traffic ........................................27
+      3.1. Current Practice in the Internet ..........................27
+      3.2. Network Control Service Class .............................27
+      3.3. OAM Service Class .........................................29
+   4. User Traffic ...................................................30
+      4.1. Telephony Service Class ...................................31
+      4.2. Signaling Service Class ...................................33
+      4.3. Multimedia Conferencing Service Class .....................35
+      4.4. Real-Time Interactive Service Class .......................37
+      4.5. Multimedia Streaming Service Class ........................39
+      4.6. Broadcast Video Service Class .............................41
+      4.7. Low-Latency Data Service Class ............................43
+      4.8. High-Throughput Data Service Class ........................45
+      4.9. Standard Service Class ....................................47
+      4.10. Low-Priority Data ........................................48
+   5. Additional Information on Service Class Usage ..................49
+      5.1. Mapping for Signaling .....................................49
+      5.2. Mapping for NTP ...........................................50
+      5.3. VPN Service Mapping .......................................50
+   6. Security Considerations ........................................51
+
+
+
+Babiarz, et al.              Informational                      [Page 2]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   7. Acknowledgements ...............................................52
+   8. Appendix A .....................................................53
+      8.1. Explanation of Ring Clipping ..............................53
+   9. References .....................................................54
+      9.1. Normative References ......................................54
+      9.2. Informative References ....................................55
+
+1.  Introduction
+
+   To aid in understanding the role of this document, we use an analogy:
+   the Differentiated Services specifications are fundamentally a
+   toolkit.  The specifications provide the equivalent of band saws,
+   planers, drill presses, and other tools.  In the hands of an expert,
+   there is no limit to what can be built, but such a toolkit can be
+   intimidating to the point of being inaccessible to a non-expert who
+   just wants to build a bookcase.  This document should be viewed as a
+   set of "project plans" for building all the (diffserv) furniture that
+   one might want.  The user may choose what to build (e.g., perhaps our
+   non-expert doesn't need a china cabinet right now), and how to go
+   about building it (e.g., plans for a non-expert probably won't employ
+   mortise/tenon construction, but that absence does not imply that
+   mortise/tenon construction is forbidden or unsound).  The authors
+   hope that these diffserv "project plans" will provide a useful guide
+   to Network Administrators in the use of diffserv techniques to
+   implement quality-of-service measures appropriate for their network's
+   traffic.
+
+   This document describes service classes configured with Diffserv and
+   recommends how they can be used and how to construct them using
+   Differentiated Services Code Points (DSCPs), traffic conditioners,
+   Per-Hop Behaviors (PHBs), 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.
+
+   Service class definitions are based on the different traffic
+   characteristics and required performance of the
+   applications/services.  This approach allows us to map current and
+   future applications/services of similar traffic characteristics and
+   performance requirements into the same service class.  Since the
+   applications'/services' characteristics and required performance are
+   end to end, the service class notion needs to be preserved end to
+   end.  With this approach, a limited set of service classes is
+   required.  For completeness, we have defined twelve different service
+   classes, two for network operation/administration and ten for
+   user/subscriber applications/services.  However, we expect that
+   network administrators will implement a subset of these classes
+
+
+
+Babiarz, et al.              Informational                      [Page 3]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   relevant to their customers and their service offerings.  Network
+   Administrators may also find it of value to add locally defined
+   service classes, although these will not necessarily enjoy end-to-end
+   properties of the same type.
+
+   Section 1 provides an introduction and overview of technologies that
+   are used for service differentiation in IP networks.  Section 2 is an
+   overview of how service classes are constructed to provide service
+   differentiation, with examples of deployment scenarios.  Section 3
+   provides configuration guidelines of service classes that are used
+   for stable operation and administration of the network.  Section 4
+   provides configuration guidelines of service classes that are used
+   for differentiation of user/subscriber traffic.  Section 5 provides
+   additional guidance on mapping different applications/protocols to
+   service classes.  Section 6 addresses security considerations.
+
+1.1.  Requirements Notation
+
+   The key words "SHOULD", "SHOULD NOT", "REQUIRED", "SHALL", "SHALL
+   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
+   this document are to be interpreted as described in [RFC2119].
+
+1.2.  Expected Use in the Network
+
+   In the Internet today, corporate LANs and ISP WANs are generally not
+   heavily utilized.  They are commonly 10% utilized at most.  For this
+   reason, congestion, loss, and variation in delay within corporate
+   LANs and ISP backbones is virtually unknown.  This clashes with user
+   perceptions, for three very good reasons.
+
+   o  The industry moves through cycles of bandwidth boom and bandwidth
+      bust, depending on prevailing market conditions and the periodic
+      deployment of new bandwidth-hungry applications.
+   o  In access networks, the state is often different.  This may be
+      because throughput rates are artificially limited or over-
+      subscribed, or because of access network design trade-offs.
+   o  Other characteristics, such as database design on web servers
+      (that may create contention points, e.g., in filestore) and
+      configuration of firewalls and routers, often look externally like
+      a bandwidth limitation.
+
+   The intent of this document is to provide a consistent marking,
+   conditioning, and packet treatment strategy so that it can be
+   configured and put into service on any link that is itself congested.
+
+
+
+
+
+
+
+Babiarz, et al.              Informational                      [Page 4]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+1.3.  Service Class Definition
+
+   A "service class" represents a set of traffic that requires specific
+   delay, loss, and jitter characteristics from the network.
+   Conceptually, a service class pertains to applications with similar
+   characteristics and performance requirements, such as a "High-
+   Throughput Data" service class for applications like the web and
+   electronic mail, or a "Telephony" service class for real-time traffic
+   such as voice and other telephony services.  Such a service class may
+   be defined locally in a Differentiated Services (DS) domain, or
+   across multiple DS domains, possibly extending end to end.
+
+   A service class as defined here is essentially a statement of the
+   required characteristics of a traffic aggregate.  The required
+   characteristics of these traffic aggregates can be realized by the
+   use of defined per-hop behavior (PHB) [RFC2474].  The actual
+   specification of the expected treatment of a traffic aggregate within
+   a domain may also be defined as a per-domain behavior (PDB)
+   [RFC3086].
+
+   Each domain may choose to implement different service classes or to
+   use different behaviors to implement the service classes or to
+   aggregate different kinds of traffic into the aggregates and still
+   achieve their required characteristics.  For example, low delay,
+   loss, and jitter may be realized using the EF PHB, or with an over-
+   provisioned AF PHB.  This must be done with care as it may disrupt
+   the end-to-end performance required by the applications/services.
+   This document provides recommendations on usage of PHBs for specific
+   service classes for their consistent implementation.  These
+   recommendations are not to be construed as prohibiting use of other
+   PHBs that realize behaviors sufficient for the relevant class of
+   traffic.
+
+   The Default Forwarding "Standard" service class is REQUIRED; all
+   other service classes are OPTIONAL.  It is expected that network
+   administrators will base their choice of the level of service
+   differentiation that they will support on their need, starting off
+   with three or four service classes for user traffic and adding others
+   as the need arises.
+
+1.4.  Key Differentiated Services Concepts
+
+   The reader SHOULD be familiar with the principles of the
+   Differentiated Services Architecture [RFC2474].  We recapitulate key
+   concepts here only to provide convenience for the reader, the
+   referenced RFCs providing the authoritative definitions.
+
+
+
+
+
+Babiarz, et al.              Informational                      [Page 5]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+1.4.1.  Queuing
+
+   A queue is a data structure that holds packets that are awaiting
+   transmission.  The packets may be delayed while in the queue,
+   possibly due to lack of bandwidth, or because it is low in priority.
+   There are a number of ways to implement a queue.  A simple model of a
+   queuing system, however, is a set of data structures for packet data,
+   which we will call queues, and a mechanism for selecting the next
+   packet from among them, which we call a scheduler.
+
+1.4.1.1.  Priority Queuing
+
+   A priority queuing system is a combination of a set of queues and a
+   scheduler that empties them in priority sequence.  When asked for a
+   packet, the scheduler inspects the highest priority queue and, if
+   there is data present, returns a packet from that queue.  Failing
+   that, it inspects the next highest priority queue, and so on.  A
+   freeway onramp with a stoplight for one lane that allows vehicles in
+   the high-occupancy-vehicle lane to pass is an example of a priority
+   queuing system; the high-occupancy-vehicle lane represents the
+   "queue" having priority.
+
+   In a priority queuing system, a packet in the highest priority queue
+   will experience a readily calculated delay.  This is proportional to
+   the amount of data remaining to be serialized when the packet arrived
+   plus the volume of the data already queued ahead of it in the same
+   queue.  The technical reason for using a priority queue relates
+   exactly to this fact: it limits delay and variations in delay and
+   should be used for traffic that has that requirement.
+
+   A priority queue or queuing system needs to avoid starvation of
+   lower-priority queues.  This may be achieved through a variety of
+   means, such as admission control, rate control, or network
+   engineering.
+
+1.4.1.2.  Rate Queuing
+
+   Similarly, a rate-based queuing system is a combination of a set of
+   queues and a scheduler that empties each at a specified rate.  An
+   example of a rate-based queuing system is a road intersection with a
+   stoplight.  The stoplight acts as a scheduler, giving each lane a
+   certain opportunity to pass traffic through the intersection.
+
+   In a rate-based queuing system, such as Weighted Fair Queuing (WFQ)
+   or Weighted Round Robin (WRR), the delay that a packet in any given
+   queue will experience depends on the parameters and occupancy of its
+   queue and the parameters and occupancy of the queues it is competing
+   with.  A queue whose traffic arrival rate is much less than the rate
+
+
+
+Babiarz, et al.              Informational                      [Page 6]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   at which it lets traffic depart will tend to be empty, and packets in
+   it will experience nominal delays.  A queue whose traffic arrival
+   rate approximates or exceeds its departure rate will tend not to be
+   empty, and packets in it will experience greater delay.  Such a
+   scheduler can impose a minimum rate, a maximum rate, or both, on any
+   queue it touches.
+
+1.4.2.  Active Queue Management
+
+   Active Queue Management, or AQM, is a generic name for any of a
+   variety of procedures that use packet dropping or marking to manage
+   the depth of a queue.  The canonical example of such a procedure is
+   Random Early Detection (RED), in that a queue is assigned a minimum
+   and maximum threshold, and the queuing algorithm maintains a moving
+   average of the queue depth.  While the mean queue depth exceeds the
+   maximum threshold, all arriving traffic is dropped.  While the mean
+   queue depth exceeds the minimum threshold but not the maximum
+   threshold, a randomly selected subset of arriving traffic is marked
+   or dropped.  This marking or dropping of traffic is intended to
+   communicate with the sending system, causing its congestion avoidance
+   algorithms to kick in.  As a result of this behavior, it is
+   reasonable to expect that TCP's cyclic behavior is desynchronized and
+   that the mean queue depth (and therefore delay) should normally
+   approximate the minimum threshold.
+
+   A variation of the algorithm is applied in Assured Forwarding PHB
+   [RFC2597], in that the behavior aggregate consists of traffic with
+   multiple DSCP marks, which are intermingled in a common queue.
+   Different minima and maxima are configured for the several DSCPs
+   separately, such that traffic that exceeds a stated rate at ingress
+   is more likely to be dropped or marked than traffic that is within
+   its contracted rate.
+
+1.4.3.  Traffic Conditioning
+
+   In addition, at the first router in a network that a packet crosses,
+   arriving traffic may be measured and dropped or marked according to a
+   policy, or perhaps shaped on network ingress, as in "A Rate Adaptive
+   Shaper for Differentiated Services" [RFC2963].  This may be used to
+   bias feedback loops, as is done in "Assured Forwarding PHB"
+   [RFC2597], or to limit the amount of traffic in a system, as is done
+   in "Expedited Forwarding PHB" [RFC3246].  Such measurement procedures
+   are collectively referred to as "traffic conditioners".  Traffic
+   conditioners are normally built using token bucket meters, for
+   example with a committed rate and burst size, as in Section 1.5.3 of
+   the DiffServ Model [RFC3290].  The Assured Forwarding PHB [RFC2597]
+   uses a variation on a meter with multiple rate and burst size
+   measurements to test and identify multiple levels of conformance.
+
+
+
+Babiarz, et al.              Informational                      [Page 7]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   Multiple rates and burst sizes can be realized using multiple levels
+   of token buckets or more complex token buckets; these are
+   implementation details.  The following are some traffic conditioners
+   that may be used in deployment of differentiated services:
+
+   o  For Class Selector (CS) PHBs, a single token bucket meter to
+      provide a rate plus burst size control.
+   o  For Expedited Forwarding (EF) PHB, a single token bucket meter to
+      provide a rate plus burst size control.
+   o  For Assured Forwarding (AF) PHBs, usually two token bucket meters
+      configured to provide behavior as outlined in "Two Rate Three
+      Color Marker (trTCM)" [RFC2698] or "Single Rate Three Color Marker
+      (srTCM)" [RFC2697].  The two-rate, three-color marker is used to
+      enforce two rates, whereas the single-rate, three-color marker is
+      used to enforce a committed rate with two burst lengths.
+
+1.4.4.  Differentiated Services Code Point (DSCP)
+
+   The DSCP is a number in the range 0..63 that is placed into an IP
+   packet to mark it according to the class of traffic it belongs in.
+   Half of these values are earmarked for standardized services, and the
+   other half of them are available for local definition.
+
+1.4.5.  Per-Hop Behavior (PHB)
+
+   In the end, the mechanisms described above are combined to form a
+   specified set of characteristics for handling different kinds of
+   traffic, depending on the needs of the application.  This document
+   seeks to identify useful traffic aggregates and to specify what PHB
+   should be applied to them.
+
+1.5.  Key Service Concepts
+
+   While Differentiated Services is a general architecture that may be
+   used to implement a variety of services, three fundamental forwarding
+   behaviors have been defined and characterized for general use.  These
+   are basic Default Forwarding (DF) behavior for elastic traffic, the
+   Assured Forwarding (AF) behavior, and the Expedited Forwarding (EF)
+   behavior for real-time (inelastic) traffic.  The facts that four code
+   points are recommended for AF and that one code point is recommended
+   for EF are arbitrary choices, and the architecture allows any
+   reasonable number of AF and EF classes simultaneously.  The choice of
+   four AF classes and one EF class in the current document is also
+   arbitrary, and operators MAY choose to operate more or fewer of
+   either.
+
+
+
+
+
+
+Babiarz, et al.              Informational                      [Page 8]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   The terms "elastic" and "real-time" are defined in [RFC1633], Section
+   3.1, as a way of understanding broad-brush application requirements.
+   This document should be reviewed to obtain a broad understanding of
+   the issues in quality of service, just as [RFC2475] should be
+   reviewed to understand the data plane architecture used in today's
+   Internet.
+
+1.5.1.  Default Forwarding (DF)
+
+   The basic forwarding behaviors applied to any class of traffic are
+   those described in [RFC2474] and [RFC2309].  Best-effort service may
+   be summarized as "I will accept your packets" and is typically
+   configured with some bandwidth guarantee.  Packets in transit may be
+   lost, reordered, duplicated, or delayed at random.  Generally,
+   networks are engineered to limit this behavior, but changing traffic
+   loads can push any network into such a state.
+
+   Application traffic in the internet that uses default forwarding is
+   expected to be "elastic" in nature.  By this, we mean that the sender
+   of traffic will adjust its transmission rate in response to changes
+   in available rate, loss, or delay.
+
+   For the basic best-effort service, a single DSCP value is provided to
+   identify the traffic, a queue to store it, and active queue
+   management to protect the network from it and to limit delays.
+
+1.5.2.  Assured Forwarding (AF)
+
+   The Assured Forwarding PHB [RFC2597] behavior is explicitly modeled
+   on Frame Relay's Discard Eligible (DE) flag or ATM's Cell Loss
+   Priority (CLP) capability.  It is intended for networks that offer
+   average-rate Service Level Agreements (SLAs) (as FR and ATM networks
+   do).  This is an enhanced best-effort service; traffic is expected to
+   be "elastic" in nature.  The receiver will detect loss or variation
+   in delay in the network and provide feedback such that the sender
+   adjusts its transmission rate to approximate available capacity.
+
+   For such behaviors, multiple DSCP values are provided (two or three,
+   perhaps more using local values) to identify the traffic, a common
+   queue to store the aggregate, and active queue management to protect
+   the network from it and to limit delays.  Traffic is metered as it
+   enters the network, and traffic is variously marked depending on the
+   arrival rate of the aggregate.  The premise is that it is normal for
+   users occasionally to use more capacity than their contract
+   stipulates, perhaps up to some bound.  However, if traffic should be
+   marked or lost to manage the queue, this excess traffic will be
+   marked or lost first.
+
+
+
+
+Babiarz, et al.              Informational                      [Page 9]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+1.5.3.  Expedited Forwarding (EF)
+
+   The intent of Expedited Forwarding PHB [RFC3246] is to provide a
+   building block for low-loss, low-delay, and low-jitter services.  It
+   can be used to build an enhanced best-effort service: traffic remains
+   subject to loss due to line errors and reordering during routing
+   changes.  However, using queuing techniques, the probability of delay
+   or variation in delay is minimized.  For this reason, it is generally
+   used to carry voice and for transport of data information that
+   requires "wire like" behavior through the IP network.  Voice is an
+   inelastic "real-time" application that sends packets at the rate the
+   codec produces them, regardless of availability of capacity.  As
+   such, this service has the potential to disrupt or congest a network
+   if not controlled.  It also has the potential for abuse.
+
+   To protect the network, at minimum one SHOULD police traffic at
+   various points to ensure that the design of a queue is not overrun,
+   and then the traffic SHOULD be given a low-delay queue (often using
+   priority, although it is asserted that a rate-based queue can do
+   this) to ensure that variation in delay is not an issue, to meet
+   application needs.
+
+1.5.4.  Class Selector (CS)
+
+   Class Selector provides support for historical codepoint definitions
+   and PHB requirement.  The Class Selector DS field provides a limited
+   backward compatibility with legacy (pre DiffServ) practice, as
+   described in [RFC2474], Section 4.  Backward compatibility is
+   addressed in two ways.  First, there are per-hop behaviors that are
+   already in widespread use (e.g., those satisfying the IPv4 Precedence
+   queuing requirements specified in [RFC1812]), and we wish to permit
+   their continued use in DS-compliant networks.  In addition, there are
+   some codepoints that correspond to historical use of the IP
+   Precedence field, and we reserve these codepoints to map to PHBs that
+   meet the general requirements specified in [RFC2474], Section
+   4.2.2.2.
+
+   No attempt is made to maintain backward compatibility with the "DTR"
+   or Type of Service (TOS) bits of the IPv4 TOS octet, as defined in
+   [RFC0791] and [RFC1349].
+
+   A DS-compliant network can be deployed with a set of one or more
+   Class Selector-compliant PHB groups.  Also, a network administrator
+   may configure the network nodes to map codepoints to PHBs,
+   irrespective of bits 3-5 of the DSCP field, to yield a network that
+   is compatible with historical IP Precedence use.  Thus, for example,
+   codepoint '011000' would map to the same PHB as codepoint '011010'.
+
+
+
+
+Babiarz, et al.              Informational                     [Page 10]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+1.5.5.  Admission Control
+
+   Admission control (including refusal when policy thresholds are
+   crossed) can ensure high-quality communication by ensuring the
+   availability of bandwidth to carry a load.  Inelastic real-time flows
+   such as Voice over Internet Protocol (VoIP) (telephony) or video
+   conferencing services can benefit from use of an admission control
+   mechanism, as generally the telephony service is configured with
+   over-subscription, meaning that some users may not be able to make a
+   call during peak periods.
+
+   For VoIP (telephony) service, a common approach is to use signaling
+   protocols such as SIP, H.323, H.248, MEGACO, and Resource Reservation
+   Protocol (RSVP) to negotiate admittance and use of network transport
+   capabilities.  When a user has been authorized to send voice traffic,
+   this admission procedure has verified that data rates will be within
+   the capacity of the network that it will use.  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.  Having thus assured a predictable input rate, the
+   network may use a priority queue to ensure nominal delay and
+   variation in delay.
+
+   Another approach that may be used in small and bandwidth-constrained
+   networks for limited number of flows is RSVP [RFC2205] [RFC2996].
+   However, there is concern with the scalability of this solution in
+   large networks where aggregation of reservations [RFC3175] is
+   considered to be required.
+
+2.  Service Differentiation
+
+   There are practical limits on the level of service differentiation
+   that should be offered in the IP networks.  We believe we have
+   defined a practical approach in delivering service differentiation by
+   defining different service classes that networks may choose to
+   support in order to provide the appropriate level of behaviors and
+   performance needed by current and future applications and services.
+   The defined structure for providing services allows several
+   applications having similar traffic characteristics and performance
+   requirements to be grouped into the same service class.  This
+   approach provides a lot of flexibility in providing the appropriate
+   level of service differentiation for current and new, yet unknown
+   applications without introducing significant changes to routers or
+   network configurations when a new traffic type is added to the
+   network.
+
+
+
+
+
+Babiarz, et al.              Informational                     [Page 11]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+2.1.  Service Classes
+
+   Traffic flowing in a network can be classified in many different
+   ways.  We have chosen to divide it into two groupings, network
+   control and user/subscriber traffic.  To provide service
+   differentiation, different service classes are defined in each
+   grouping.  The network control traffic group can further be divided
+   into two service classes (see Section 3 for detailed definition of
+   each service class):
+
+   o  "Network Control" for routing and network control function.
+   o  "OAM" (Operations, Administration, and Management) for network
+      configuration and management functions.
+
+   The user/subscriber traffic group is broken down into ten service
+   classes to provide service differentiation for all the different
+   types of applications/services (see Section 4 for detailed definition
+   of each service class):
+
+   o  Telephony service class is best suited for applications that
+      require very low delay variation and are of constant rate, such as
+      IP telephony (VoIP) and circuit emulation over IP applications.
+   o  Signaling service class is best suited for peer-to-peer and
+      client-server signaling and control functions using protocols such
+      as SIP, SIP-T, H.323, H.248, and Media Gateway Control Protocol
+      (MGCP).
+   o  Multimedia Conferencing service class is best suited for
+      applications that require very low delay and have the ability to
+      change encoding rate (rate adaptive), such as H.323/V2 and later
+      video conferencing service.
+   o  Real-Time Interactive service class is intended for interactive
+      variable rate inelastic applications that require low jitter and
+      loss and very low delay, such as interactive gaming applications
+      that use RTP/UDP streams for game control commands, and video
+      conferencing applications that do not have the ability to change
+      encoding rates or to mark packets with different importance
+      indications.
+   o  Multimedia Streaming service class is best suited for variable
+      rate elastic streaming media applications where a human is waiting
+      for output and where the application has the capability to react
+      to packet loss by reducing its transmission rate, such as
+      streaming video and audio and webcast.
+   o  Broadcast Video service class is best suited for inelastic
+      streaming media applications that may be of constant or variable
+      rate, requiring low jitter and very low packet loss, such as
+      broadcast TV and live events, video surveillance, and security.
+
+
+
+
+
+Babiarz, et al.              Informational                     [Page 12]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   o  Low-Latency Data service class is best suited for data processing
+      applications where a human is waiting for output, such as web-
+      based ordering or an Enterprise Resource Planning (ERP)
+      application.
+   o  High-Throughput Data service class is best suited for store and
+      forward applications such as FTP and billing record transfer.
+   o  Standard service class is for traffic that has not been identified
+      as requiring differentiated treatment and is normally referred to
+      as best effort.
+   o  Low-Priority Data service class is intended for packet flows where
+      bandwidth assurance is not required.
+
+2.2.  Categorization of User Service Classes
+
+   The ten defined user/subscriber service classes listed above can be
+   grouped into a small number of application categories.  For some
+   application categories, it was felt that more than one service class
+   was needed to provide service differentiation within that category
+   due to the different traffic characteristic of the applications,
+   control function, and the required flow behavior.  Figure 1 provides
+   a summary of service class grouping into four application categories.
+
+   Application Control Category
+
+   o  The Signaling service class is intended to be used to control
+      applications or user endpoints.  Examples of protocols that would
+      use this service class are SIP or H.248 for IP telephone service
+      and SIP or Internet Group Management Protocol (IGMP) for control
+      of broadcast TV service to subscribers.  Although user signaling
+      flows have similar performance requirements as Low-Latency Data,
+      they need to be distinguished and marked with a different DSCP.
+      The essential distinction is something like "administrative
+      control and management" of the traffic affected as the protocols
+      in this class tend to be tied to the media stream/session they
+      signal and control.
+
+   Media-Oriented Category
+
+   Due to the vast number of new (in process of being deployed) and
+   already-in-use media-oriented services in IP networks, five service
+   classes have been defined.
+
+   o  Telephony service class is intended for IP telephony (VoIP)
+      service.  It may also be used for other applications that meet the
+      defined traffic characteristics and performance requirements.
+   o  Real-Time Interactive service class is intended for inelastic
+      video flows from applications such as SIP-based desktop video
+      conferencing applications and for interactive gaming.
+
+
+
+Babiarz, et al.              Informational                     [Page 13]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   o  Multimedia Conferencing service class is for video conferencing
+      solutions that have the ability to reduce their transmission rate
+      on detection of congestion.  These flows can therefore be
+      classified as rate adaptive.  As currently two types of video
+      conferencing equipment are used in IP networks (ones that generate
+      inelastic traffic and ones that generate rate-adaptive traffic),
+      two service class are needed.  The Real-Time Interactive service
+      class should be used for equipment that generates inelastic video
+      flows and the Multimedia Conferencing service class for equipment
+      that generates rate-adaptive video flows.
+   o  Broadcast Video service class is to be used for inelastic traffic
+      flows, which are intended for broadcast TV service and for
+      transport of live video and audio events.
+   o  Multimedia Streaming service class is to be used for elastic
+      multimedia traffic flows.  This multimedia content is typically
+      stored before being transmitted.  It is also buffered at the
+      receiving end before being played out.  The buffering is
+      sufficiently large to accommodate any variation in transmission
+      rate that is encountered in the network.  Multimedia entertainment
+      over IP delivery services that are being developed can generate
+      both elastic and inelastic traffic flows; therefore, two service
+      classes are defined to address this space, respectively:
+      Multimedia Streaming and Broadcast Video.
+
+   Data Category
+
+   The data category is divided into three service classes.
+
+   o  Low-Latency Data for applications/services that require low delay
+      or latency for bursty but short-lived flows.
+   o  High-Throughput Data for applications/services that require good
+      throughput for long-lived bursty flows.  High Throughput and
+      Multimedia Steaming are close in their traffic flow
+      characteristics with High Throughput being a bit more bursty and
+      not as long-lived as Multimedia Streaming.
+   o  Low-Priority Data for applications or services that can tolerate
+      short or long interruptions of packet flows.  The Low-Priority
+      Data service class can be viewed as "don't care" to some degree.
+
+   Best-Effort Category
+
+   o  All traffic that is not differentiated in the network falls into
+      this category and is mapped into the Standard service class.  If a
+      packet is marked with a DSCP value that is not supported in the
+      network, it SHOULD be forwarded using the Standard service class.
+
+
+
+
+
+
+Babiarz, et al.              Informational                     [Page 14]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   Figure 1, below, provides a grouping of the defined user/subscriber
+   service classes into four categories, with indications of which ones
+   use an independent flow for signaling or control; type of flow
+   behavior (elastic, rate adaptive, or inelastic); and the last column
+   provides end user Quality of Service (QoS) rating as defined in ITU-T
+   Recommendation G.1010.
+
+    -----------------------------------------------------------------
+   | Application |    Service    | Signaled |  Flow     |   G.1010   |
+   |  Categories |     Class     |          | Behavior  |   Rating   |
+   |-------------+---------------+----------+-----------+------------|
+   | Application |   Signaling   |   Not    | Inelastic | Responsive |
+   |   Control   |               |applicable|           |            |
+   |-------------+---------------+----------+-----------+------------|
+   |             |   Telephony   |   Yes    | Inelastic | Interactive|
+   |             |---------------+----------+-----------+------------|
+   |             |   Real-Time   |   Yes    | Inelastic | Interactive|
+   |             |  Interactive  |          |           |            |
+   |             |---------------+----------+-----------+------------|
+   |    Media-   |   Multimedia  |   Yes    |    Rate   | Interactive|
+   |   Oriented  |  Conferencing |          |  Adaptive |            |
+   |             |---------------+----------+-----------+------------|
+   |             |Broadcast Video|   Yes    | Inelastic | Responsive |
+   |             |---------------+----------+-----------+------------|
+   |             |  Multimedia   |   Yes    |  Elastic  |   Timely   |
+   |             |   Streaming   |          |           |            |
+   |-------------+---------------+----------+-----------+------------|
+   |             |  Low-Latency  |    No    |  Elastic  | Responsive |
+   |             |     Data      |          |           |            |
+   |             |---------------+----------+-----------+------------|
+   |   Data      |High-Throughput|    No    |  Elastic  |   Timely   |
+   |             |    Data       |          |           |            |
+   |             |---------------+----------+-----------+------------|
+   |             | Low-Priority  |    No    |  Elastic  |Non-critical|
+   |             |    Data       |          |           |            |
+   |-------------+---------------+----------+-----------+------------|
+   | Best Effort |   Standard    |    Not Specified     |Non-critical|
+    -----------------------------------------------------------------
+
+           Figure 1. User/Subscriber Service Classes Grouping
+
+
+
+
+
+
+
+
+
+
+
+Babiarz, et al.              Informational                     [Page 15]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   Here is a short explanation of the end user QoS category as defined
+   in ITU-T Recommendation G.1010.  User traffic is divided into four
+   different categories, namely, interactive, responsive, timely, and
+   non-critical.  An example of interactive traffic is between two
+   humans and is most sensitive to delay, loss, and jitter.  Another
+   example of interactive traffic is between two servers where very low
+   delay and loss are needed.  Responsive traffic is typically between a
+   human and a server but can also be between two servers.  Responsive
+   traffic is less affected by jitter and can tolerate longer delays
+   than interactive traffic.  Timely traffic is either between servers
+   or servers and humans and the delay tolerance is significantly longer
+   than responsive traffic.  Non-critical traffic is normally between
+   servers/machines where delivery may be delay for period of time.
+
+2.3.  Service Class Characteristics
+
+   This document provides guidelines for network administrators in
+   configuring their network for the level of service differentiation
+   that is appropriate in their network to meet their QoS needs.  It is
+   expected that network operators will configure and provide in their
+   networks a subset of the defined service classes.  Our intent is to
+   provide guidelines for configuration of Differentiated Services for a
+   wide variety of applications, services, and network configurations.
+   In addition, network administrators may choose to define and deploy
+   other service classes in their network.
+
+   Figure 2 provides a behavior view for traffic serviced by each
+   service class.  The traffic characteristics column defines the
+   characteristics and profile of flows serviced, and the tolerance to
+   loss, delay, and jitter columns define the treatment the flows will
+   receive.  End-to-end quantitative performance requirements may be
+   obtained from ITU-T Recommendations Y.1541 and Y.1540.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Babiarz, et al.              Informational                     [Page 16]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+    -------------------------------------------------------------------
+   |Service Class  |                              |    Tolerance to    |
+   |    Name       |  Traffic Characteristics     | Loss |Delay |Jitter|
+   |===============+==============================+======+======+======|
+   |   Network     |Variable size packets, mostly |      |      |      |
+   |   Control     |inelastic short messages, but |  Low |  Low | Yes  |
+   |               | traffic can also burst (BGP) |      |      |      |
+   |---------------+------------------------------+------+------+------|
+   |               | Fixed-size small packets,    | Very | Very | Very |
+   |  Telephony    | constant emission rate,      |  Low |  Low |  Low |
+   |               | inelastic and low-rate flows |      |      |      |
+   |---------------+------------------------------+------+------+------|
+   |   Signaling   | Variable size packets, some  | Low  | Low  |  Yes |
+   |               | what bursty short-lived flows|      |      |      |
+   |---------------+------------------------------+------+------+------|
+   |  Multimedia   | Variable size packets,       | Low  | Very |      |
+   | Conferencing  | constant transmit interval,  |  -   | Low  | Low  |
+   |               |rate adaptive, reacts to loss |Medium|      |      |
+   |---------------+------------------------------+------+------+------|
+   |   Real-Time   | RTP/UDP streams, inelastic,  | Low  | Very | Low  |
+   |  Interactive  | mostly variable rate         |      | Low  |      |
+   |---------------+------------------------------+------+------+------|
+   |  Multimedia   |  Variable size packets,      |Low - |Medium|  Yes |
+   |   Streaming   | elastic with variable rate   |Medium|      |      |
+   |---------------+------------------------------+------+------+------|
+   |   Broadcast   | Constant and variable rate,  | Very |Medium|  Low |
+   |     Video     | inelastic, non-bursty flows  |  Low |      |      |
+   |---------------+------------------------------+------+------+------|
+   |  Low-Latency  | Variable rate, bursty short- | Low  |Low - |  Yes |
+   |      Data     |  lived elastic flows         |      |Medium|      |
+   |---------------+------------------------------+------+------+------|
+   |      OAM      |  Variable size packets,      | Low  |Medium|  Yes |
+   |               |  elastic & inelastic flows   |      |      |      |
+   |---------------+------------------------------+------+------+------|
+   |High-Throughput| Variable rate, bursty long-  | Low  |Medium|  Yes |
+   |      Data     |   lived elastic flows        |      |- High|      |
+   |---------------+------------------------------+------+------+------|
+   |   Standard    | A bit of everything          |  Not Specified     |
+   |---------------+------------------------------+------+------+------|
+   | Low-Priority  | Non-real-time and elastic    | High | High | Yes  |
+   |      Data     |                              |      |      |      |
+    -------------------------------------------------------------------
+
+               Figure 2. Service Class Characteristics
+
+
+
+
+
+
+
+Babiarz, et al.              Informational                     [Page 17]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   Notes for Figure 2: A "Yes" in the jitter-tolerant column implies
+   that data is buffered in the endpoint and that a moderate level of
+   network-induced variation in delay will not affect the application.
+   Applications that use TCP as a transport are generally good examples.
+   Routing protocols and peer-to-peer signaling also fall in this class;
+   although loss can create problems in setting up calls, a moderate
+   level of jitter merely makes call placement a little less predictable
+   in duration.
+
+   Service classes indicate the required traffic forwarding treatment in
+   order to meet user, application, or network expectations.  Section 3
+   defines the service classes that MAY be used for forwarding network
+   control traffic, and Section 4 defines the service classes that MAY
+   be used for forwarding user traffic with examples of intended
+   application types mapped into each service class.  Note that the
+   application types are only examples and are not meant to be all-
+   inclusive or prescriptive.  Also, note that the service class naming
+   or ordering does not imply any priority ordering.  They are simply
+   reference names that are used in this document with associated QoS
+   behaviors that are optimized for the particular application types
+   they support.  Network administrators MAY choose to assign different
+   service class names to the service classes that they will support.
+   Figure 3 defines the RECOMMENDED relationship between service classes
+   and DS codepoint assignment with application examples.  It is
+   RECOMMENDED that this relationship be preserved end to end.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Babiarz, et al.              Informational                     [Page 18]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+    ------------------------------------------------------------------
+   |   Service     |  DSCP   |    DSCP     |       Application        |
+   |  Class Name   |  Name   |    Value    |        Examples          |
+   |===============+=========+=============+==========================|
+   |Network Control|  CS6    |   110000    | Network routing          |
+   |---------------+---------+-------------+--------------------------|
+   | Telephony     |   EF    |   101110    | IP Telephony bearer      |
+   |---------------+---------+-------------+--------------------------|
+   |  Signaling    |  CS5    |   101000    | IP Telephony signaling   |
+   |---------------+---------+-------------+--------------------------|
+   | Multimedia    |AF41,AF42|100010,100100|   H.323/V2 video         |
+   | Conferencing  |  AF43   |   100110    |  conferencing (adaptive) |
+   |---------------+---------+-------------+--------------------------|
+   |  Real-Time    |  CS4    |   100000    | Video conferencing and   |
+   |  Interactive  |         |             | Interactive gaming       |
+   |---------------+---------+-------------+--------------------------|
+   | Multimedia    |AF31,AF32|011010,011100| Streaming video and      |
+   | Streaming     |  AF33   |   011110    |   audio on demand        |
+   |---------------+---------+-------------+--------------------------|
+   |Broadcast Video|  CS3    |   011000    |Broadcast TV & live events|
+   |---------------+---------+-------------+--------------------------|
+   | Low-Latency   |AF21,AF22|010010,010100|Client/server transactions|
+   |   Data        |  AF23   |   010110    | Web-based ordering       |
+   |---------------+---------+-------------+--------------------------|
+   |     OAM       |  CS2    |   010000    |         OAM&P            |
+   |---------------+---------+-------------+--------------------------|
+   |High-Throughput|AF11,AF12|001010,001100|  Store and forward       |
+   |    Data       |  AF13   |   001110    |     applications         |
+   |---------------+---------+-------------+--------------------------|
+   |    Standard   | DF (CS0)|   000000    | Undifferentiated         |
+   |               |         |             | applications             |
+   |---------------+---------+-------------+--------------------------|
+   | Low-Priority  |  CS1    |   001000    | Any flow that has no BW  |
+   |     Data      |         |             | assurance                |
+    ------------------------------------------------------------------
+
+                Figure 3. DSCP to Service Class Mapping
+
+   Notes for Figure 3: Default Forwarding (DF) and Class Selector 0
+   (CS0) provide equivalent behavior and use the same DS codepoint,
+   '000000'.
+
+   It is expected that network administrators will base their choice of
+   the service classes that they will support on their need, starting
+   off with three or four service classes for user traffic and adding
+   others as the need arises.
+
+
+
+
+
+Babiarz, et al.              Informational                     [Page 19]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   Figure 4 provides a summary of DiffServ QoS mechanisms that SHOULD be
+   used for the defined service classes that are further detailed in
+   Sections 3 and 4 of this document.  According to what
+   applications/services need to be differentiated, network
+   administrators can choose the service class(es) that need to be
+   supported in their network.
+
+    ------------------------------------------------------------------
+   |  Service      | DSCP | Conditioning at   |   PHB   | Queuing| AQM|
+   |   Class       |      |    DS Edge        |  Used   |        |    |
+   |===============+======+===================+=========+========+====|
+   |Network Control| CS6  | See Section 3.1   | RFC2474 |  Rate  | Yes|
+   |---------------+------+-------------------+---------+--------+----|
+   |   Telephony   |  EF  |Police using sr+bs | RFC3246 |Priority| No |
+   |---------------+------+-------------------+---------+--------+----|
+   |   Signaling   | CS5  |Police using sr+bs | RFC2474 |  Rate  | No |
+   |---------------+------+-------------------+---------+--------+----|
+   |   Multimedia  | AF41 |  Using two-rate,  |         |        | Yes|
+   | Conferencing  | AF42 |three-color marker | RFC2597 |  Rate  | per|
+   |               | AF43 | (such as RFC 2698)|         |        |DSCP|
+   |---------------+------+-------------------+---------+--------+----|
+   |   Real-Time   | CS4  |Police using sr+bs | RFC2474 |  Rate  | No |
+   |   Interactive |      |                   |         |        |    |
+   |---------------+------+-------------------+---------|--------+----|
+   |  Multimedia   | AF31 |  Using two-rate,  |         |        | Yes|
+   |  Streaming    | AF32 |three-color marker | RFC2597 |  Rate  | per|
+   |               | AF33 | (such as RFC 2698)|         |        |DSCP|
+   |---------------+------+-------------------+---------+--------+----|
+   |Broadcast Video| CS3  |Police using sr+bs | RFC2474 |  Rate  | No |
+   |---------------+------+-------------------+---------+--------+----|
+   |    Low-       | AF21 | Using single-rate,|         |        | Yes|
+   |    Latency    | AF22 |three-color marker | RFC2597 |  Rate  | per|
+   |    Data       | AF23 | (such as RFC 2697)|         |        |DSCP|
+   |---------------+------+-------------------+---------+--------+----|
+   |     OAM       | CS2  |Police using sr+bs | RFC2474 |  Rate  | Yes|
+   |---------------+------+-------------------+---------+--------+----|
+   |    High-      | AF11 |  Using two-rate,  |         |        | Yes|
+   |  Throughput   | AF12 |three-color marker | RFC2597 |  Rate  | per|
+   |    Data       | AF13 | (such as RFC 2698)|         |        |DSCP|
+   |---------------+------+-------------------+---------+--------+----|
+   |   Standard    | DF   | Not applicable    | RFC2474 |  Rate  | Yes|
+   |---------------+------+-------------------+---------+--------+----|
+   | Low-Priority  | CS1  | Not applicable    | RFC3662 |  Rate  | Yes|
+   |     Data      |      |                   |         |        |    |
+    ------------------------------------------------------------------
+
+     Figure 4. Summary of QoS Mechanisms Used for Each Service Class
+
+
+
+
+Babiarz, et al.              Informational                     [Page 20]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   Notes for Figure 4:
+
+   o  Conditioning at DS edge means that traffic conditioning is
+      performed at the edge of the DiffServ network where untrusted user
+      devices are connected or between two DiffServ networks.
+   o  "sr+bs" represents a policing mechanism that provides single rate
+      with burst size control.
+   o  The single-rate, three-color marker (srTCM) behavior SHOULD be
+      equivalent to RFC 2697, and the two-rate, three-color marker
+      (trTCM) behavior SHOULD be equivalent to RFC 2698.
+   o  The PHB for Real-Time Interactive service class SHOULD be
+      configured to provide high bandwidth assurance.  It MAY be
+      configured as a second EF PHB that uses relaxed performance
+      parameters and a rate scheduler.
+   o  The PHB for Broadcast Video service class SHOULD be configured to
+      provide high bandwidth assurance.  It MAY be configured as a third
+      EF PHB that uses relaxed performance parameters and a rate
+      scheduler.
+   o  In network segments that use IP precedence marking, only one of
+      the two service classes can be supported, High-Throughput Data or
+      Low-Priority Data.  We RECOMMEND that the DSCP value(s) of the
+      unsupported service class be changed to 000xx1 on ingress and
+      changed back to original value(s) on egress of the network segment
+      that uses precedence marking.  For example, if Low-Priority Data
+      is mapped to Standard service class, then 000001 DSCP marking MAY
+      be used to distinguish it from Standard marked packets on egress.
+
+2.4.  Deployment Scenarios
+
+   It is expected that network administrators will base their choice of
+   the service classes that they will support on their need, starting
+   off with three or four service classes for user traffic and adding
+   more service classes as the need arises.  In this section, we provide
+   three examples of possible deployment scenarios.
+
+2.4.1.  Example 1
+
+   A network administrator determines that he needs to provide different
+   performance levels (quality of service) in his network for the
+   services that he will be offering to his customers.  He needs to
+   enable his network to provide:
+
+
+
+
+
+
+
+
+
+
+Babiarz, et al.              Informational                     [Page 21]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   o  Reliable VoIP (telephony) service, equivalent to Public Switched
+      Telephone Network (PSTN).
+   o  A low-delay assured bandwidth data service.
+   o  Support for current Internet services.
+
+   For this example, the network administrator's needs are addressed
+   with the deployment of the following six service classes:
+
+   o  Network Control service class for routing and control traffic that
+      is needed for reliable operation of the provider's network.
+   o  Standard service class for all traffic that will receive normal
+      (undifferentiated) forwarding treatment through the network for
+      support of current Internet service.
+   o  Telephony service class for VoIP (telephony) bearer traffic.
+   o  Signaling service class for Telephony signaling to control the
+      VoIP service.
+   o  Low-Latency Data service class for the low-delay assured bandwidth
+      differentiated data service.
+   o  OAM service class for operation and management of the network.
+
+   Figure 5 provides a summary of the mechanisms needed for delivery of
+   service differentiation for Example 1.
+
+    -------------------------------------------------------------------
+   |  Service      |  DSCP | Conditioning at   |   PHB   |        |    |
+   |   Class       |       |    DS Edge        |  Used   | Queuing| AQM|
+   |===============+=======+===================+=========+========+====|
+   |Network Control|  CS6  | See Section 3.1   | RFC2474 |  Rate  | Yes|
+   |---------------+-------+-------------------+---------+--------+----|
+   |  Telephony    |   EF  |Police using sr+bs | RFC3246 |Priority| No |
+   |---------------+-------+-------------------+---------+--------+----|
+   |  Signaling    |  CS5  |Police using sr+bs | RFC2474 |  Rate  | No |
+   |---------------+-------+-------------------+---------+--------+----|
+   |    Low-       | AF21  | Using single-rate,|         |        | Yes|
+   |   Latency     | AF22  |three-color marker | RFC2597 |  Rate  | per|
+   |    Data       | AF23  | (such as RFC 2697)|         |        |DSCP|
+   |---------------+-------+-------------------+---------+--------+----|
+   |      OAM      |  CS2  |Police using sr+bs | RFC2474 |  Rate  | Yes|
+   |---------------+-------+-------------------+---------+--------+----|
+   |   Standard    |DF(CS0)| Not applicable    | RFC2474 |  Rate  | Yes|
+   |               | +other|                   |         |        |    |
+    -------------------------------------------------------------------
+
+       Figure 5. Service Provider Network Configuration Example 1
+
+
+
+
+
+
+
+Babiarz, et al.              Informational                     [Page 22]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   Notes for Figure 5:
+
+   o  "sr+bs" represents a policing mechanism that provides single rate
+      with burst size control.
+   o  The single-rate, three-color marker (srTCM) behavior SHOULD be
+      equivalent to RFC 2697.
+   o  Any packet that is marked with DSCP value that is not represented
+      by the supported service classes SHOULD be forwarded using the
+      Standard service class.
+
+2.4.2.  Example 2
+
+   With this example, we show how network operators with Example 1
+   capabilities can evolve their service offering to provide three new
+   additional services to their customers.  The new additional service
+   capabilities that are to be added are:
+
+   o  SIP-based desktop video conference capability to complement VoIP
+      (telephony) service.
+   o  TV and on-demand movie viewing service to residential subscribers.
+   o  Network-based data storage and file backup service to business
+      customers.
+
+   The new additional services that the network administrator would like
+   to offer are addressed with the deployment of the following four
+   additional service classes (these are additions to the six service
+   classes already defined in Example 1):
+
+   o  Real-Time Interactive service class for transport of MPEG-4 real-
+      time video flows to support desktop video conferencing.  The
+      control/signaling for video conferencing is done using the
+      Signaling service class.
+   o  Broadcast Video service class for transport of IPTV broadcast
+      information.  The channel selection and control is via IGMP mapped
+      into the Signaling service class.
+   o  Multimedia Streaming service class for transport of stored MPEG-2
+      or MPEG-4 content.  The selection and control of streaming
+      information is done using the Signaling service class.  The
+      selection of Multimedia Streaming service class for on-demand
+      movie service was chosen as the set-top box used for this service
+      has local buffering capability to compensate for the bandwidth
+      variability of the elastic streaming information.  Note that if
+      transport of on-demand movie service is inelastic, then the
+      Broadcast Video service class SHOULD be used.
+   o  High-Throughput Data service class is for transport of bulk data
+      for network-based storage and file backup service to business
+      customers.
+
+
+
+
+Babiarz, et al.              Informational                     [Page 23]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   Figure 6 provides a summary of the mechanisms needed for delivery of
+   service differentiation for all the service classes used in Example
+   2.
+
+    -------------------------------------------------------------------
+   |  Service      |  DSCP | Conditioning at   |   PHB   |        |    |
+   |   Class       |       |    DS Edge        |  Used   | Queuing| AQM|
+   |===============+=======+===================+=========+========+====|
+   |Network Control|  CS6  | See Section 3.1   | RFC2474 |  Rate  |Yes |
+   |---------------+-------+-------------------+---------+--------+----|
+   |  Telephony    |   EF  |Police using sr+bs | RFC3246 |Priority| No |
+   |---------------+-------+-------------------+---------+--------+----|
+   |  Signaling    |  CS5  |Police using sr+bs | RFC2474 |  Rate  | No |
+   |---------------+-------+-------------------+---------+--------+----|
+   |  Real-time    |  CS4  |Police using sr+bs | RFC2474 |  Rate  | No |
+   |  Interactive  |       |                   |         |        |    |
+   |---------------+-------+-------------------+---------+--------+----|
+   |Broadcast Video|  CS3  |Police using sr+bs | RFC2474 |  Rate  | No |
+   |---------------+-------+-------------------+---------+--------+----|
+   |  Multimedia   | AF31  |  Using two-rate,  |         |        |Yes |
+   |  Streaming    | AF32  |three-color marker | RFC2597 |  Rate  |per |
+   |               | AF33  | (such as RFC 2698)|         |        |DSCP|
+   |---------------+-------+-------------------+---------+--------+----|
+   |    Low-       | AF21  | Using single-rate,|         |        |Yes |
+   |   Latency     | AF22  |three-color marker | RFC2597 |  Rate  |per |
+   |    Data       | AF23  | (such as RFC 2697)|         |        |DSCP|
+   |---------------+-------+-------------------+---------+--------+----|
+   |      OAM      |  CS2  |Police using sr+bs | RFC2474 |  Rate  |Yes |
+   |---------------+-------+-------------------+---------+--------+----|
+   |    High-      | AF11  |  Using two-rate,  |         |        |Yes |
+   |  Throughput   | AF12  |three-color marker | RFC2597 |  Rate  |per |
+   |    Data       | AF13  | (such as RFC 2698)|         |        |DSCP|
+   |---------------+-------+-------------------+---------+--------+----|
+   |   Standard    |DF(CS0)| Not applicable    | RFC2474 |  Rate  |Yes |
+   |               | +other|                   |         |        |    |
+    -------------------------------------------------------------------
+
+       Figure 6. Service Provider Network Configuration Example 2
+
+   Notes for Figure 6:
+
+   o  "sr+bs" represents a policing mechanism that provides single rate
+      with burst size control.
+   o  The single-rate, three-color marker (srTCM) behavior SHOULD be
+      equivalent to RFC 2697, and the two-rate, three-color marker
+      (trTCM) behavior SHOULD be equivalent to RFC 2698.
+
+
+
+
+
+Babiarz, et al.              Informational                     [Page 24]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   o  Any packet that is marked with DSCP value that is not represented
+      by the supported service classes SHOULD be forwarded using the
+      Standard service class.
+
+2.4.3.  Example 3
+
+   An enterprise network administrator determines that they need to
+   provide different performance levels (quality of service) in their
+   network for the new services that are being offered to corporate
+   users.  The enterprise network needs to:
+
+   o  Provide reliable corporate VoIP service.
+   o  Provide video conferencing service to selected Conference Rooms.
+   o  Support on-demand distribution of prerecorded audio and video
+      information to large number of users.
+   o  Provide a priority data transfer capability for engineering teams
+      to share design information.
+   o  Reduce or deny bandwidth during peak traffic periods for selected
+      applications.
+   o  Continue to provide normal IP service to all remaining
+      applications and services.
+
+   For this example, the enterprise's network needs are addressed with
+   the deployment of the following nine service classes:
+
+   o  Network Control service class for routing and control traffic that
+      is needed for reliable operation of the enterprise network.
+   o  OAM service class for operation and management of the network.
+   o  Standard service class for all traffic that will receive normal
+      (undifferentiated) forwarding treatment.
+   o  Telephony service class for VoIP (telephony) bearer traffic.
+   o  Signaling service class for Telephony signaling to control the
+      VoIP service.
+   o  Multimedia Conferencing service class for support of inter-
+      Conference Room video conferencing service using H.323/V2 or
+      similar equipment.
+   o  Multimedia Streaming service class for transfer of prerecorded
+      audio and video information.
+   o  High-Throughput Data service class to provide bandwidth assurance
+      for timely transfer of large engineering files.
+   o  Low-Priority Data service class for selected background
+      applications where data transfer can be delayed or suspended for a
+      period of time during peak network load conditions.
+
+
+
+
+
+
+
+
+Babiarz, et al.              Informational                     [Page 25]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   Figure 7 provides a summary of the mechanisms needed for delivery of
+   service differentiation for Example 3.
+
+    -------------------------------------------------------------------
+   |  Service      |  DSCP | Conditioning at   |   PHB   |        |    |
+   |   Class       |       |    DS Edge        |  Used   | Queuing| AQM|
+   |===============+=======+===================+=========+========+====|
+   |Network Control|  CS6  | See Section 3.2   | RFC2474 |  Rate  | Yes|
+   |---------------+-------+-------------------+---------+--------+----|
+   |  Telephony    |   EF  |Police using sr+bs | RFC3246 |Priority| No |
+   |---------------+-------+-------------------+---------+--------+----|
+   |  Signaling    |  CS5  |Police using sr+bs | RFC2474 |  Rate  | No |
+   |---------------+-------+-------------------+---------+--------+----|
+   |  Multimedia   | AF41  |  Using two-rate,  |         |        | Yes|
+   | Conferencing  | AF42  | three-color marker| RFC2597 |  Rate  | per|
+   |               | AF43  | (such as RFC 2698)|         |        |DSCP|
+   |---------------+-------+-------------------+---------+--------+----|
+   |  Multimedia   | AF31  |  Using two-rate,  |         |        | Yes|
+   |   Streaming   | AF32  | three-color marker| RFC2597 |  Rate  | per|
+   |               | AF33  | (such as RFC 2698)|         |        |DSCP|
+   |---------------+-------+-------------------+---------+--------+----|
+   |      OAM      |  CS2  |Police using sr+bs | RFC2474 |  Rate  | Yes|
+   |---------------+-------+-------------------+---------+--------+----|
+   |    High-      | AF11  |  Using two-rate,  |         |        |Yes |
+   |   Throughput  | AF12  |three-color marker | RFC2597 |  Rate  |per |
+   |    Data       | AF13  | (such as RFC 2698)|         |        |DSCP|
+   |---------------+-------+-------------------+---------+--------+----|
+   | Low-Priority  |  CS1  | Not applicable    | RFC3662 |  Rate  | Yes|
+   |     Data      |       |                   |         |        |    |
+   |---------------+-------+-------------------+---------+--------+----|
+   |   Standard    |DF(CS0)| Not applicable    | RFC2474 |  Rate  | Yes|
+   |               | +other|                   |         |        |    |
+    -------------------------------------------------------------------
+
+           Figure 7. Enterprise Network Configuration Example
+
+   Notes for Figure 7:
+
+   o  "sr+bs" represents a policing mechanism that provides single rate
+      with burst size control.
+   o  The single-rate, three-color marker (srTCM) behavior SHOULD be
+      equivalent to RFC 2697, and the two-rate, three-color marker
+      (trTCM) behavior SHOULD be equivalent to RFC 2698.
+   o  Any packet that is marked with DSCP value that is not represented
+      by the supported service classes SHOULD be forwarded using the
+      Standard service class.
+
+
+
+
+
+Babiarz, et al.              Informational                     [Page 26]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+3.  Network Control Traffic
+
+   Network control traffic is defined as packet flows that are essential
+   for stable operation of the administered network as well as for
+   information that may be exchanged between neighboring networks across
+   a peering point where SLAs are in place.  Network control traffic is
+   different from user application control (signaling) that may be
+   generated by some applications or services.  Network control traffic
+   is mostly between routers and network nodes that are used for
+   operating, administering, controlling, or managing the network
+   segments.  Network Control Traffic may be split into two service
+   classes, i.e., Network Control and OAM.
+
+3.1.  Current Practice in the Internet
+
+   Based on today's routing protocols and network control procedures
+   that are used in the Internet, we have determined that CS6 DSCP value
+   SHOULD be used for routing and control and that CS7 DSCP value SHOULD
+   be reserved for future use, potentially for future routing or control
+   protocols.  Network administrators MAY use a Local/Experimental DSCP;
+   therefore, they may use a locally defined service class within their
+   network to further differentiate their routing and control traffic.
+
+   RECOMMENDED Network Edge Conditioning for CS7 DSCP marked packets:
+
+   o  Drop or remark CS7 packets at ingress to DiffServ network domain.
+   o  CS7 marked packets SHOULD NOT be sent across peering points.
+      Exchange of control information across peering points SHOULD be
+      done using CS6 DSCP and the Network Control service class.
+
+3.2.  Network Control Service Class
+
+   The Network Control service class is used for transmitting packets
+   between network devices (routers) that require control (routing)
+   information to be exchanged between nodes within the administrative
+   domain as well as across a peering point between different
+   administrative domains.  Traffic transmitted in this service class is
+   very important as it keeps the network operational, and it needs to
+   be forwarded in a timely manner.
+
+   The Network Control service class SHOULD be configured using the
+   DiffServ Class Selector (CS) PHB, defined in [RFC2474].  This service
+   class SHOULD be configured so that the traffic receives a minimum
+   bandwidth guarantee, to ensure that the packets always receive timely
+   service.  The configured forwarding resources for Network Control
+   service class SHOULD be such that the probability of packet drop
+   under peak load is very low in this service class.  The Network
+
+
+
+
+Babiarz, et al.              Informational                     [Page 27]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   Control service class SHOULD be configured to use a Rate Queuing
+   system such as defined in Section 1.4.1.2 of this document.
+
+   The following are examples of protocols and applications that SHOULD
+   use the Network Control service class:
+
+   o  Routing packet flows: OSPF, BGP, ISIS, RIP.
+   o  Control information exchange within and between different
+      administrative domains across a peering point where SLAs are in
+      place.
+   o  LSP setup using CR-LDP and RSVP-TE.
+
+   The following protocols and applications SHOULD NOT use the Network
+   Control service class:
+
+   o  User traffic.
+
+   The following are 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).
+   o  User traffic is not allowed to use this service class.  By user
+      traffic, we mean packet flows that originate from user-controlled
+      end points that are connected to the network.
+
+   The RECOMMENDED DSCP marking is CS6 (Class Selector 6).
+
+   RECOMMENDED Network Edge Conditioning:
+
+   o  At peering points (between two DiffServ networks) where SLAs are
+      in place, CS6 marked packets SHOULD be policed, e.g., using a
+      single rate with burst size (sr+bs) token bucket policer to keep
+      the CS6 marked packet flows to within the traffic rate specified
+      in the SLA.
+   o  CS6 marked packet flows from untrusted sources (for example, end
+      user devices) SHOULD be dropped or remarked at ingress to the
+      DiffServ network.
+   o  Packets from users/subscribers are not permitted access to the
+      Network Control service classes.
+
+   The fundamental service offered to the Network Control service class
+   is enhanced best-effort service with high bandwidth assurance.  Since
+   this service class is used to forward both elastic and inelastic
+   flows, the service SHOULD be engineered so that the Active Queue
+   Management (AQM) [RFC2309] is applied to CS6 marked packets.
+
+
+
+
+Babiarz, et al.              Informational                     [Page 28]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   If RED [RFC2309] is used as an AQM algorithm, the min-threshold
+   specifies a target queue depth, and the max-threshold specifies the
+   queue depth above which all traffic is dropped or ECN marked.  Thus,
+   in this service class, the following inequality should hold in queue
+   configurations:
+
+   o  min-threshold CS6 < max-threshold CS6
+   o  max-threshold CS6 <= memory assigned to the queue
+
+   Note: Many other AQM algorithms exist and are used; they should be
+   configured to achieve a similar result.
+
+3.3.  OAM Service Class
+
+   The OAM (Operations, Administration, and Management) service class is
+   RECOMMENDED for OAM&P (Operations, Administration, and Management and
+   Provisioning) using protocols such as Simple Network Management
+   Protocol (SNMP), Trivial File Transfer Protocol (TFTP), FTP, Telnet,
+   and Common Open Policy Service (COPS).  Applications using this
+   service class require a low packet loss but are relatively not
+   sensitive to delay.  This service class is configured to provide good
+   packet delivery for intermittent flows.
+
+   The OAM service class SHOULD use the Class Selector (CS) PHB defined
+   in [RFC2474].  This service class SHOULD be configured to provide a
+   minimum bandwidth assurance for CS2 marked packets to ensure that
+   they get forwarded.  The OAM service class SHOULD be configured to
+   use a Rate Queuing system such as defined in Section 1.4.1.2 of this
+   document.
+
+   The following applications SHOULD use the OAM service class:
+
+   o  Provisioning and configuration of network elements.
+   o  Performance monitoring of network elements.
+   o  Any network operational alarms.
+
+   The following are traffic characteristics:
+
+   o  Variable size packets.
+   o  Intermittent traffic flows.
+   o  Traffic may burst at times.
+   o  Both elastic and inelastic flows.
+   o  Traffic not sensitive to delays.
+
+   RECOMMENDED DSCP marking:
+
+   o  All flows in this service class are marked with CS2 (Class
+      Selector 2).
+
+
+
+Babiarz, et al.              Informational                     [Page 29]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   Applications or IP end points SHOULD pre-mark their packets with CS2
+   DSCP value.  If the end point is not capable of setting the DSCP
+   value, then the router topologically closest to the end point SHOULD
+   perform Multifield (MF) Classification, as defined in [RFC2475].
+
+   RECOMMENDED conditioning performed at DiffServ network edge:
+
+   o  Packet flow marking (DSCP setting) from untrusted sources (end
+      user devices) SHOULD be verified at ingress to DiffServ network
+      using Multifield (MF) Classification methods, defined in
+      [RFC2475].
+   o  Packet flows from untrusted sources (end user devices) SHOULD be
+      policed at ingress to DiffServ network, e.g., using single rate
+      with burst size token bucket policer to ensure that the traffic
+      stays within its negotiated or engineered bounds.
+   o  Packet flows from trusted sources (routers inside administered
+      network) MAY not require policing.
+   o  Normally OAM&P CS2 marked packet flows are not allowed to flow
+      across peering points.  If that is the case, then CS2 marked
+      packets SHOULD be policed (dropped) at both egress and ingress
+      peering interfaces.
+
+   The fundamental service offered to "OAM" traffic is enhanced best-
+   effort service with controlled rate.  The service SHOULD be
+   engineered so that CS2 marked packet flows have sufficient bandwidth
+   in the network to provide high assurance of delivery.  Since this
+   service class is used to forward both elastic and inelastic flows,
+   the service SHOULD be engineered so that Active Queue Management
+   [RFC2309] is applied to CS2 marked packets.
+
+   If RED [RFC2309] is used as an AQM algorithm, the min-threshold
+   specifies a target queue depth for each DSCP, and the max-threshold
+   specifies the queue depth above which all traffic with such a DSCP is
+   dropped or ECN marked.  Thus, in this service class, the following
+   inequality should hold in queue configurations:
+
+   o  min-threshold CS2 < max-threshold CS2
+   o  max-threshold CS2 <= memory assigned to the queue
+
+   Note: Many other AQM algorithms exist and are used; they should be
+   configured to achieve a similar result.
+
+4.  User Traffic
+
+   User traffic is defined as packet flows between different users or
+   subscribers.  It is the traffic that is sent to or from end-terminals
+   and that supports a very wide variety of applications and services.
+   User traffic can be differentiated in many different ways; therefore,
+
+
+
+Babiarz, et al.              Informational                     [Page 30]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   we investigated several different approaches to classifying user
+   traffic.  We looked at differentiating user traffic as real-time
+   versus non-real-time, elastic or rate-adaptive versus inelastic,
+   sensitive versus insensitive to loss as well as traffic
+   categorization as interactive, responsive, timely, and non-critical,
+   as defined in ITU-T Recommendation G.1010.  In the final analysis, we
+   used all of the above for service differentiation, mapping
+   application types that seemed to have different sets of performance
+   sensitivities, and requirements to different service classes.
+
+   Network administrators can categorize their applications according to
+   the type of behavior that they require and MAY choose to support all
+   or a subset of the defined service classes.  Figure 3 provides some
+   common applications and the forwarding service classes that best
+   support them, based on their performance requirements.
+
+4.1.  Telephony Service Class
+
+   The Telephony service class is RECOMMENDED for applications that
+   require real-time, very low delay, very low jitter, and very low
+   packet loss for relatively constant-rate traffic sources (inelastic
+   traffic sources).  This service class SHOULD be used for IP telephony
+   service.
+
+   The fundamental service offered to traffic in the Telephony service
+   class is minimum jitter, delay, and packet loss service up to a
+   specified upper bound.  Operation is in some respect similar to an
+   ATM CBR service, which has guaranteed bandwidth and which, if it
+   stays within the negotiated rate, experiences nominal delay and no
+   loss.  The EF PHB has a similar guarantee.
+
+   Typical configurations negotiate the setup of telephone calls over
+   IP, using protocols such as H.248, MEGACO, H.323, or SIP.  When a
+   user has been authorized to send telephony traffic, the call
+   admission procedure should have verified that the newly admitted flow
+   will be within the capacity of the Telephony service class forwarding
+   capability in the network.  For VoIP (telephony) service, call
+   admission control is usually performed by a telephony call server/
+   gatekeeper using signaling (SIP, H.323, H.248, MEGACO, etc.) on
+   access points to the network.  The bandwidth in the core network and
+   the number of simultaneous VoIP sessions that can be supported needs
+   to be engineered and controlled so that there is no congestion for
+   this service.  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.
+
+
+
+
+Babiarz, et al.              Informational                     [Page 31]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   The Telephony service class SHOULD use Expedited Forwarding (EF) PHB,
+   as defined in [RFC3246], and SHOULD be configured to receive
+   guaranteed forwarding resources so that all packets are forwarded
+   quickly.  The Telephony service class SHOULD be configured to use a
+   Priority Queuing system such as that defined in Section 1.4.1.1 of
+   this document.
+
+   The following applications SHOULD use the Telephony service class:
+
+   o  VoIP (G.711, G.729 and other codecs).
+   o  Voice-band data over IP (modem, fax).
+   o  T.38 fax over IP.
+   o  Circuit emulation over IP, virtual wire, etc.
+   o  IP Virtual Private Network (VPN) service that specifies single-
+      rate, mean network delay that is slightly longer then network
+      propagation delay, very low jitter, and a very low packet loss.
+
+   The following are traffic characteristics:
+
+   o  Mostly fixed-size packets for VoIP (60, 70, 120 or 200 bytes in
+      size).
+   o  Packets emitted at constant time intervals.
+   o  Admission control of new flows is provided by telephony call
+      server, media gateway, gatekeeper, edge router, end terminal, or
+      access node that provides flow admission control function.
+
+   Applications or IP end points SHOULD pre-mark their packets with EF
+   DSCP value.  If the end point is not capable of setting the DSCP
+   value, then the router topologically closest to the end point SHOULD
+   perform Multifield (MF) Classification, as defined in [RFC2475].
+
+   The RECOMMENDED DSCP marking is EF for the following applications:
+
+   o  VoIP (G.711, G.729 and other codecs).
+   o  Voice-band data over IP (modem and fax).
+   o  T.38 fax over IP.
+   o  Circuit emulation over IP, virtual wire, etc.
+
+   RECOMMENDED Network Edge Conditioning:
+
+   o  Packet flow marking (DSCP setting) from untrusted sources (end
+      user devices) SHOULD be verified at ingress to DiffServ network
+      using Multifield (MF) Classification methods, defined in
+      [RFC2475].
+   o  Packet flows from untrusted sources (end user devices) SHOULD be
+      policed at ingress to DiffServ network, e.g., using single rate
+      with burst size token bucket policer to ensure that the telephony
+      traffic stays within its negotiated bounds.
+
+
+
+Babiarz, et al.              Informational                     [Page 32]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   o  Policing is OPTIONAL for packet flows from trusted sources whose
+      behavior is ensured via other means (e.g., administrative controls
+      on those systems).
+   o  Policing of Telephony packet flows across peering points where SLA
+      is in place is OPTIONAL as telephony traffic will be controlled by
+      admission control mechanism between peering points.
+
+   The fundamental service offered to "Telephony" traffic is enhanced
+   best-effort service with controlled rate, very low delay, and very
+   low loss.  The service MUST be engineered so that EF marked packet
+   flows have sufficient bandwidth in the network to provide guaranteed
+   delivery.  Normally traffic in this service class does not respond
+   dynamically to packet loss.  As such, Active Queue Management
+   [RFC2309] SHOULD NOT be applied to EF marked packet flows.
+
+4.2.  Signaling Service Class
+
+   The Signaling service class is RECOMMENDED for delay-sensitive
+   client-server (traditional telephony) and peer-to-peer application
+   signaling.  Telephony signaling includes signaling between IP phone
+   and soft-switch, soft-client and soft-switch, and media gateway and
+   soft-switch as well as peer-to-peer using various protocols.  This
+   service class is intended to be used for control of sessions and
+   applications.  Applications using this service class require a
+   relatively fast response, as there are typically several messages of
+   different sizes sent for control of the session.  This service class
+   is configured to provide good response for short-lived, intermittent
+   flows that require real-time packet forwarding.  To minimize the
+   possibility of ring clipping at start of call for VoIP service that
+   interfaces to a circuit switch Exchange in the Public Switched
+   Telephone Network (PSTN), the Signaling service class SHOULD be
+   configured so that the probability of packet drop or significant
+   queuing delay under peak load is very low in IP network segments that
+   provide this interface.  The term "ring clipping" refers to those
+   instances where the front end of a ringing signal is altered because
+   the bearer path is not made available in time to carry all of the
+   audible ringing signal.  This condition may occur due to a race
+   condition between when the tone generator in the circuit switch
+   Exchange is turned on and when the bearer path through the IP network
+   is enabled.  See Section 8.1 for additional explanation of "ring
+   clipping" and Section 5.1 for explanation of mapping different
+   signaling methods to service classes.
+
+   The Signaling service class SHOULD use the Class Selector (CS) PHB,
+   defined in [RFC2474].  This service class SHOULD be configured to
+   provide a minimum bandwidth assurance for CS5 marked packets to
+   ensure that they get forwarded.  The Signaling service class SHOULD
+
+
+
+
+Babiarz, et al.              Informational                     [Page 33]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   be configured to use a Rate Queuing system such as that defined in
+   Section 1.4.1.2 of this document.
+
+   The following applications SHOULD use the Signaling service class:
+
+   o  Peer-to-peer IP telephony signaling (e.g., using SIP, H.323).
+   o  Peer-to-peer signaling for multimedia applications (e.g., using
+      SIP, H.323).
+   o  Peer-to-peer real-time control function.
+   o  Client-server IP telephony signaling using H.248, MEGACO, MGCP, IP
+      encapsulated ISDN, or other proprietary protocols.
+   o  Signaling to control IPTV applications using protocols such as
+      IGMP.
+   o  Signaling flows between high-capacity telephony call servers or
+      soft switches using protocol such as SIP-T.  Such high-capacity
+      devices may control thousands of telephony (VoIP) calls.
+
+   The following are traffic characteristics:
+
+   o  Variable size packets, normally one packet at a time.
+   o  Intermittent traffic flows.
+   o  Traffic may burst at times.
+   o  Delay-sensitive control messages sent between two end points.
+
+   RECOMMENDED DSCP marking:
+
+   o  All flows in this service class are marked with CS5 (Class
+      Selector 5).
+
+   Applications or IP end points SHOULD pre-mark their packets with CS5
+   DSCP value.  If the end point is not capable of setting the DSCP
+   value, then the router topologically closest to the end point SHOULD
+   perform Multifield (MF) Classification, as defined in [RFC2475].
+
+   RECOMMENDED conditioning performed at DiffServ network edge:
+
+   o  Packet flow marking (DSCP setting) from untrusted sources (end
+      user devices) SHOULD be verified at ingress to DiffServ network
+      using Multifield (MF) Classification methods defined in [RFC2475].
+   o  Packet flows from untrusted sources (end user devices) SHOULD be
+      policed at ingress to DiffServ network, e.g., using single rate
+      with burst size token bucket policer to ensure that the traffic
+      stays within its negotiated or engineered bounds.
+   o  Packet flows from trusted sources (application servers inside
+      administered network) MAY not require policing.
+   o  Policing of packet flows across peering points SHOULD be performed
+      to the Service Level Agreement (SLA).
+
+
+
+
+Babiarz, et al.              Informational                     [Page 34]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   The fundamental service offered to "Signaling" traffic is enhanced
+   best-effort service with controlled rate and delay.  The service
+   SHOULD be engineered so that CS5 marked packet flows have sufficient
+   bandwidth in the network to provide high assurance of delivery and
+   low delay.  Normally, traffic in this service class does not respond
+   dynamically to packet loss.  As such, Active Queue Management
+   [RFC2309] SHOULD NOT be applied to CS5 marked packet flows.
+
+4.3.  Multimedia Conferencing Service Class
+
+   The Multimedia Conferencing service class is RECOMMENDED for
+   applications that require real-time service for rate-adaptive
+   traffic.  H.323/V2 and later versions of video conferencing equipment
+   with dynamic bandwidth adjustment are such applications.  The traffic
+   sources in this service class have the ability to dynamically change
+   their transmission rate based on feedback from the receiver.  One
+   approach used in H.323/V2 equipment is, when the receiver detects a
+   pre-configured level of packet loss, it signals to the transmitter
+   the indication of possible on-path congestion.  When available, the
+   transmitter then selects a lower rate encoding codec.  Note that
+   today, many H.323/V2 video conferencing solutions implement fixed-
+   step bandwidth change (usually reducing the rate), traffic resembling
+   step-wise CBR.
+
+   Typical video conferencing configurations negotiate the setup of
+   multimedia session using protocols such as H.323.  When a user/end-
+   point has been authorized to start a multimedia session, the
+   admission procedure should have verified that the newly admitted data
+   rate will be within the engineered capacity of the Multimedia
+   Conferencing service class.  The bandwidth in the core network and
+   the number of simultaneous video conferencing sessions that can be
+   supported SHOULD be engineered to control traffic load for this
+   service.
+
+   The Multimedia Conferencing service class SHOULD use the Assured
+   Forwarding (AF) PHB, defined in [RFC2597].  This service class SHOULD
+   be configured to provide a bandwidth assurance for AF41, AF42, and
+   AF43 marked packets to ensure that they get forwarded.  The
+   Multimedia Conferencing service class SHOULD be configured to use a
+   Rate Queuing system such as that defined in Section 1.4.1.2 of this
+   document.
+
+   The following applications SHOULD use the Multimedia Conferencing
+   service class:
+
+   o  H.323/V2 and later versions of video conferencing applications
+      (interactive video).
+
+
+
+
+Babiarz, et al.              Informational                     [Page 35]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   o  Video conferencing applications with rate control or traffic
+      content importance marking.
+   o  Application server-to-application server non-bursty data transfer
+      requiring very low delay.
+   o  IP VPN service that specifies two rates and mean network delay
+      that is slightly longer then network propagation delay.
+   o  Interactive, time-critical, and mission-critical applications.
+
+   The following are traffic characteristics:
+
+   o  Variable size packets.
+   o  The higher the rate, the higher the density of large packets.
+   o  Constant packet emission time interval.
+   o  Variable rate.
+   o  Source is capable of reducing its transmission rate based on
+      detection of packet loss at the receiver.
+
+   Applications or IP end points SHOULD pre-mark their packets with DSCP
+   values as shown below.  If the end point is not capable of setting
+   the DSCP value, then the router topologically closest to the end
+   point SHOULD perform Multifield (MF) Classification, as defined in
+   [RFC2475] and mark all packets as AF4x.  Note: In this case, the
+   two-rate, three-color marker will be configured to operate in Color-
+   Blind mode.
+
+   RECOMMENDED DSCP marking when performed by router closest to source:
+
+   o  AF41 = up to specified rate "A".
+   o  AF42 = in excess of specified rate "A" but below specified rate
+      "B".
+   o  AF43 = in excess of specified rate "B".
+   o  Where "A" < "B".
+
+   Note: One might expect "A" to approximate the sum of the mean rates
+   and "B" to approximate the sum of the peak rates.
+
+   RECOMMENDED DSCP marking when performed by H.323/V2 video
+   conferencing equipment:
+
+   o  AF41 = H.323 video conferencing audio stream RTP/UDP.
+   o  AF41 = H.323 video conferencing video control RTCP/TCP.
+   o  AF41 = H.323 video conferencing video stream up to specified rate
+      "A".
+   o  AF42 = H.323 video conferencing video stream in excess of
+      specified rate "A" but below specified rate "B".
+   o  AF43 = H.323 video conferencing video stream in excess of
+      specified rate "B".
+   o  Where "A" < "B".
+
+
+
+Babiarz, et al.              Informational                     [Page 36]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   RECOMMENDED conditioning performed at DiffServ network edge:
+
+   o  The two-rate, three-color marker SHOULD be configured to provide
+      the behavior as defined in trTCM [RFC2698].
+   o  If packets are marked by trusted sources or a previously trusted
+      DiffServ domain and the color marking is to be preserved, then the
+      two-rate, three-color marker SHOULD be configured to operate in
+      Color-Aware mode.
+   o  If the packet marking is not trusted or the color marking is not
+      to be preserved, then the two-rate, three-color marker SHOULD be
+      configured to operate in Color-Blind mode.
+
+   The fundamental service offered to "Multimedia Conferencing" traffic
+   is enhanced best-effort service with controlled rate and delay.  For
+   video conferencing service, typically a 1% packet loss detected at
+   the receiver triggers an encoding rate change, dropping to the next
+   lower provisioned video encoding rate.  As such, Active Queue
+   Management [RFC2309] SHOULD be used primarily to switch the video
+   encoding rate under congestion, changing from high rate to lower
+   rate, i.e., 1472 kbps to 768 kbps.  The probability of loss of AF41
+   traffic MUST NOT exceed the probability of loss of AF42 traffic,
+   which in turn MUST NOT exceed the probability of loss of AF43
+   traffic.
+
+   If RED [RFC2309] is used as an AQM algorithm, the min-threshold
+   specifies a target queue depth for each DSCP, and the max-threshold
+   specifies the queue depth above which all traffic with such a DSCP is
+   dropped or ECN marked.  Thus, in this service class, the following
+   inequality should hold in queue configurations:
+
+   o  min-threshold AF43 < max-threshold AF43
+   o  max-threshold AF43 <= min-threshold AF42
+   o  min-threshold AF42 < max-threshold AF42
+   o  max-threshold AF42 <= min-threshold AF41
+   o  min-threshold AF41 < max-threshold AF41
+   o  max-threshold AF41 <= memory assigned to the queue
+
+   Note: This configuration tends to drop AF43 traffic before AF42 and
+   AF42 before AF41.  Many other AQM algorithms exist and are used; they
+   should be configured to achieve a similar result.
+
+4.4.  Real-Time Interactive Service Class
+
+   The Real-Time Interactive service class is RECOMMENDED for
+   applications that require low loss and jitter and very low delay for
+   variable rate inelastic traffic sources.  Interactive gaming and
+   video conferencing applications that do not have the ability to
+   change encoding rates or to mark packets with different importance
+
+
+
+Babiarz, et al.              Informational                     [Page 37]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   indications are such applications.  The traffic sources in this
+   traffic class do not have the ability to reduce their transmission
+   rate according to feedback received from the receiving end.
+
+   Typically, applications in this service class are configured to
+   negotiate the setup of RTP/UDP control session.  When a user/end-
+   point has been authorized to start a new session, the admission
+   procedure should have verified that the newly admitted data rates
+   will be within the engineered capacity of the Real-Time Interactive
+   service class.  The bandwidth in the core network and the number of
+   simultaneous Real-time Interactive sessions that can be supported
+   SHOULD be engineered to control traffic load for this service.
+
+   The Real-Time Interactive service class SHOULD use the Class Selector
+   (CS) PHB, defined in [RFC2474].  This service class SHOULD be
+   configured to provide a high assurance for bandwidth for CS4 marked
+   packets to ensure that they get forwarded.  The Real-Time Interactive
+   service class SHOULD be configured to use a Rate Queuing system such
+   as that defined in Section 1.4.1.2 of this document.  Note that this
+   service class MAY be configured as a second EF PHB that uses relaxed
+   performance parameter, a rate scheduler, and CS4 DSCP value.
+
+   The following applications SHOULD use the Real-Time Interactive
+   service class:
+
+   o  Interactive gaming and control.
+   o  Video conferencing applications without rate control or traffic
+      content importance marking.
+   o  IP VPN service that specifies single rate and mean network delay
+      that is slightly longer then network propagation delay.
+   o  Inelastic, interactive, time-critical, and mission-critical
+      applications requiring very low delay.
+
+   The following are traffic characteristics:
+
+   o  Variable size packets.
+   o  Variable rate, non-bursty.
+   o  Application is sensitive to delay variation between flows and
+      sessions.
+   o  Lost packets, if any, are usually ignored by application.
+
+   RECOMMENDED DSCP marking:
+
+   o  All flows in this service class are marked with CS4 (Class
+      Selector 4).
+
+
+
+
+
+
+Babiarz, et al.              Informational                     [Page 38]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   Applications or IP end points SHOULD pre-mark their packets with CS4
+   DSCP value.  If the end point is not capable of setting the DSCP
+   value, then the router topologically closest to the end point SHOULD
+   perform Multifield (MF) Classification, as defined in [RFC2475].
+
+   RECOMMENDED conditioning performed at DiffServ network edge:
+
+   o  Packet flow marking (DSCP setting) from untrusted sources (end
+      user devices) SHOULD be verified at ingress to DiffServ network
+      using Multifield (MF) Classification methods defined in [RFC2475].
+   o  Packet flows from untrusted sources (end user devices) SHOULD be
+      policed at ingress to DiffServ network, e.g., using single rate
+      with burst size token bucket policer to ensure that the traffic
+      stays within its negotiated or engineered bounds.
+   o  Packet flows from trusted sources (application servers inside
+      administered network) MAY not require policing.
+   o  Policing of packet flows across peering points SHOULD be performed
+      to the Service Level Agreement (SLA).
+
+   The fundamental service offered to "Real-Time Interactive" traffic is
+   enhanced best-effort service with controlled rate and delay.  The
+   service SHOULD be engineered so that CS4 marked packet flows have
+   sufficient bandwidth in the network to provide high assurance of
+   delivery.  Normally, traffic in this service class does not respond
+   dynamically to packet loss.  As such, Active Queue Management
+   [RFC2309] SHOULD NOT be applied to CS4 marked packet flows.
+
+4.5.  Multimedia Streaming Service Class
+
+   The Multimedia Streaming service class is RECOMMENDED for
+   applications that require near-real-time packet forwarding of
+   variable rate elastic traffic sources that are not as delay sensitive
+   as applications using the Multimedia Conferencing service class.
+   Such applications include streaming audio and video, some video
+   (movies) on-demand applications, and webcasts.  In general, the
+   Multimedia Streaming service class assumes that the traffic is
+   buffered at the source/destination; therefore, it is less sensitive
+   to delay and jitter.
+
+   The Multimedia Streaming service class SHOULD use the Assured
+   Forwarding (AF) PHB, defined in [RFC2597].  This service class SHOULD
+   be configured to provide a minimum bandwidth assurance for AF31,
+   AF32, and AF33 marked packets to ensure that they get forwarded.  The
+   Multimedia Streaming service class SHOULD be configured to use Rate
+   Queuing system such as that defined in Section 1.4.1.2 of this
+   document.
+
+
+
+
+
+Babiarz, et al.              Informational                     [Page 39]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   The following applications SHOULD use the Multimedia Streaming
+   service class:
+
+   o  Buffered streaming audio (unicast).
+   o  Buffered streaming video (unicast).
+   o  Webcasts.
+   o  IP VPN service that specifies two rates and is less sensitive to
+      delay and jitter.
+
+   The following are traffic characteristics:
+   o  Variable size packets.
+   o  The higher the rate, the higher the density of large packets.
+   o  Variable rate.
+   o  Elastic flows.
+   o  Some bursting at start of flow from some applications.
+
+   Applications or IP end points SHOULD pre-mark their packets with DSCP
+   values as shown below.  If the end point is not capable of setting
+   the DSCP value, then the router topologically closest to the end
+   point SHOULD perform Multifield (MF) Classification, as defined in
+   [RFC2475], and mark all packets as AF3x.  Note: In this case, the
+   two-rate, three-color marker will be configured to operate in Color-
+   Blind mode.
+
+   RECOMMENDED DSCP marking:
+
+   o  AF31 = up to specified rate "A".
+   o  AF32 = in excess of specified rate "A" but below specified rate
+      "B".
+   o  AF33 = in excess of specified rate "B".
+   o  Where "A" < "B".
+
+   Note: One might expect "A" to approximate the sum of the mean rates
+   and "B" to approximate the sum of the peak rates.
+
+   RECOMMENDED conditioning performed at DiffServ network edge:
+
+   o  The two-rate, three-color marker SHOULD be configured to provide
+      the behavior as defined in trTCM [RFC2698].
+   o  If packets are marked by trusted sources or a previously trusted
+      DiffServ domain and the color marking is to be preserved, then the
+      two-rate, three-color marker SHOULD be configured to operate in
+      Color-Aware mode.
+   o  If the packet marking is not trusted or the color marking is not
+      to be preserved, then the two-rate, three-color marker SHOULD be
+      configured to operate in Color-Blind mode.
+
+
+
+
+
+Babiarz, et al.              Informational                     [Page 40]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   The fundamental service offered to "Multimedia Streaming" traffic is
+   enhanced best-effort service with controlled rate and delay.  The
+   service SHOULD be engineered so that AF31 marked packet flows have
+   sufficient bandwidth in the network to provide high assurance of
+   delivery.  Since the AF3x traffic is elastic and responds dynamically
+   to packet loss, Active Queue Management [RFC2309] SHOULD be used
+   primarily to reduce forwarding rate to the minimum assured rate at
+   congestion points.  The probability of loss of AF31 traffic MUST NOT
+   exceed the probability of loss of AF32 traffic, which in turn MUST
+   NOT exceed the probability of loss of AF33.
+
+   If RED [RFC2309] is used as an AQM algorithm, the min-threshold
+   specifies a target queue depth for each DSCP, and the max-threshold
+   specifies the queue depth above which all traffic with such a DSCP is
+   dropped or ECN marked.  Thus, in this service class, the following
+   inequality should hold in queue configurations:
+
+   o  min-threshold AF33 < max-threshold AF33
+   o  max-threshold AF33 <= min-threshold AF32
+   o  min-threshold AF32 < max-threshold AF32
+   o  max-threshold AF32 <= min-threshold AF31
+   o  min-threshold AF31 < max-threshold AF31
+   o  max-threshold AF31 <= memory assigned to the queue
+
+   Note: This configuration tends to drop AF33 traffic before AF32 and
+   AF32 before AF31.  Note: Many other AQM algorithms exist and are
+   used; they should be configured to achieve a similar result.
+
+4.6.  Broadcast Video Service Class
+
+   The Broadcast Video service class is RECOMMENDED for applications
+   that require near-real-time packet forwarding with very low packet
+   loss of constant rate and variable rate inelastic traffic sources
+   that are not as delay sensitive as applications using the Real-Time
+   Interactive service class.  Such applications include broadcast TV,
+   streaming of live audio and video events, some video-on-demand
+   applications, and video surveillance.  In general, the Broadcast
+   Video service class assumes that the destination end point has a
+   dejitter buffer, for video application usually a 2 - 8 video-frame
+   buffer (66 to several hundred of milliseconds), and therefore that it
+   is less sensitive to delay and jitter.
+
+   The Broadcast Video service class SHOULD use the Class Selector (CS)
+   PHB, defined in [RFC2474].  This service class SHOULD be configured
+   to provide high assurance for bandwidth for CS3 marked packets to
+   ensure that they get forwarded.  The Broadcast Video service class
+   SHOULD be configured to use Rate Queuing system such as that defined
+   in Section 1.4.1.2 of this document.  Note that this service class
+
+
+
+Babiarz, et al.              Informational                     [Page 41]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   MAY be configured as a third EF PHB that uses relaxed performance
+   parameter, a rate scheduler, and CS3 DSCP value.
+
+   The following applications SHOULD use the Broadcast Video service
+   class:
+
+   o  Video surveillance and security (unicast).
+   o  TV broadcast including HDTV (multicast).
+   o  Video on demand (unicast) with control (virtual DVD).
+   o  Streaming of live audio events (both unicast and multicast).
+   o  Streaming of live video events (both unicast and multicast).
+
+   The following are traffic characteristics:
+
+   o  Variable size packets.
+   o  The higher the rate, the higher the density of large packets.
+   o  Mixture of variable rate and constant rate flows.
+   o  Fixed packet emission time intervals.
+   o  Inelastic flows.
+
+   RECOMMENDED DSCP marking:
+
+   o  All flows in this service class are marked with CS3 (Class
+      Selector 3).
+   o  In some cases, such as those for security and video surveillance
+      applications, it may be desirable to use a different DSCP marking.
+      If so, then locally user definable (EXP/LU) codepoints in the
+      range '011xx1' MAY be used to provide unique traffic
+      identification.  The locally user definable (EXP/LU) codepoint(s)
+      MAY be associated with the PHB that is used for CS3 traffic.
+      Furthermore, depending on the network scenario, additional network
+      edge conditioning policy MAY be needed for the EXP/LU codepoint(s)
+      used.
+
+   Applications or IP end points SHOULD pre-mark their packets with CS3
+   DSCP value.  If the end point is not capable of setting the DSCP
+   value, then the router topologically closest to the end point SHOULD
+   perform Multifield (MF) Classification, as defined in [RFC2475].
+
+   RECOMMENDED conditioning performed at DiffServ network edge:
+
+   o  Packet flow marking (DSCP setting) from untrusted sources (end
+      user devices) SHOULD be verified at ingress to DiffServ network
+      using Multifield (MF) Classification methods defined in [RFC2475].
+   o  Packet flows from untrusted sources (end user devices) SHOULD be
+      policed at ingress to DiffServ network, e.g., using single rate
+      with burst size token bucket policer to ensure that the traffic
+      stays within its negotiated or engineered bounds.
+
+
+
+Babiarz, et al.              Informational                     [Page 42]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   o  Packet flows from trusted sources (application servers inside
+      administered network) MAY not require policing.
+   o  Policing of packet flows across peering points SHOULD be performed
+      to the Service Level Agreement (SLA).
+
+   The fundamental service offered to "Broadcast Video" traffic is
+   enhanced best-effort service with controlled rate and delay.  The
+   service SHOULD be engineered so that CS3 marked packet flows have
+   sufficient bandwidth in the network to provide high assurance of
+   delivery.  Normally, traffic in this service class does not respond
+   dynamically to packet loss.  As such, Active Queue Management
+   [RFC2309] SHOULD NOT be applied to CS3 marked packet flows.
+
+4.7.  Low-Latency Data Service Class
+
+   The Low-Latency Data service class is RECOMMENDED for elastic and
+   responsive typically client-/server-based applications.  Applications
+   forwarded by this service class are those that require a relatively
+   fast response and typically have asymmetrical bandwidth need, i.e.,
+   the client typically sends a short message to the server and the
+   server responds with a much larger data flow back to the client.  The
+   most common example of this is when a user clicks a hyperlink (~ few
+   dozen bytes) on a web page, resulting in a new web page to be loaded
+   (Kbytes of data).  This service class is configured to provide good
+   response for TCP [RFC1633] short-lived flows that require real-time
+   packet forwarding of variable rate traffic sources.
+
+   The Low-Latency Data service class SHOULD use the Assured Forwarding
+   (AF) PHB, defined in [RFC2597].  This service class SHOULD be
+   configured to provide a minimum bandwidth assurance for AF21, AF22,
+   and AF23 marked packets to ensure that they get forwarded.  The Low-
+   Latency Data service class SHOULD be configured to use a Rate Queuing
+   system such as that defined in Section 1.4.1.2 of this document.
+
+   The following applications SHOULD use the Low-Latency Data service
+   class:
+
+   o  Client/server applications.
+   o  Systems Network Architecture (SNA) terminal to host transactions
+      (SNA over IP using Data Link Switching (DLSw)).
+   o  Web-based transactions (E-commerce).
+   o  Credit card transactions.
+   o  Financial wire transfers.
+   o  Enterprise Resource Planning (ERP) applications (e.g., SAP/BaaN).
+   o  VPN service that supports Committed Information Rate (CIR) with up
+      to two burst sizes.
+
+
+
+
+
+Babiarz, et al.              Informational                     [Page 43]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   The following are traffic characteristics:
+
+   o  Variable size packets.
+   o  Variable packet emission rate.
+   o  With packet bursts of TCP window size.
+   o  Short traffic bursts.
+   o  Source capable of reducing its transmission rate based on
+      detection of packet loss at the receiver or through explicit
+      congestion notification.
+
+   Applications or IP end points SHOULD pre-mark their packets with DSCP
+   values as shown below.  If the end point is not capable of setting
+   the DSCP value, then the router topologically closest to the end
+   point SHOULD perform Multifield (MF) Classification, as defined in
+   [RFC2475] and mark all packets as AF2x.  Note: In this case, the
+   single-rate, three-color marker will be configured to operate in
+   Color-Blind mode.
+
+   RECOMMENDED DSCP marking:
+
+   o  AF21 = flow stream with packet burst size up to "A" bytes.
+   o  AF22 = flow stream with packet burst size in excess of "A" but
+      below "B" bytes.
+   o  AF23 = flow stream with packet burst size in excess of "B" bytes.
+   o  Where "A" < "B".
+
+   RECOMMENDED conditioning performed at DiffServ network edge:
+
+   o  The single-rate, three-color marker SHOULD be configured to
+      provide the behavior as defined in srTCM [RFC2697].
+   o  If packets are marked by trusted sources or a previously trusted
+      DiffServ domain and the color marking is to be preserved, then the
+      single-rate, three-color marker SHOULD be configured to operate in
+      Color-Aware mode.
+   o  If the packet marking is not trusted or the color marking is not
+      to be preserved, then the single-rate, three-color marker SHOULD
+      be configured to operate in Color-Blind mode.
+
+   The fundamental service offered to "Low-Latency Data" traffic is
+   enhanced best-effort service with controlled rate and delay.  The
+   service SHOULD be engineered so that AF21 marked packet flows have
+   sufficient bandwidth in the network to provide high assurance of
+   delivery.  Since the AF2x traffic is elastic and responds dynamically
+   to packet loss, Active Queue Management [RFC2309] SHOULD be used
+   primarily to control TCP flow rates at congestion points by dropping
+   packets from TCP flows that have large burst size.  The probability
+   of loss of AF21 traffic MUST NOT exceed the probability of loss of
+   AF22 traffic, which in turn MUST NOT exceed the probability of loss
+
+
+
+Babiarz, et al.              Informational                     [Page 44]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   of AF23.  Explicit Congestion Notification (ECN) [RFC3168] MAY also
+   be used with Active Queue Management.
+
+   If RED [RFC2309] is used as an AQM algorithm, the min-threshold
+   specifies a target queue depth for each DSCP, and the max-threshold
+   specifies the queue depth above which all traffic with such a DSCP is
+   dropped or ECN marked.  Thus, in this service class, the following
+   inequality should hold in queue configurations:
+
+   o  min-threshold AF23 < max-threshold AF23
+   o  max-threshold AF23 <= min-threshold AF22
+   o  min-threshold AF22 < max-threshold AF22
+   o  max-threshold AF22 <= min-threshold AF21
+   o  min-threshold AF21 < max-threshold AF21
+   o  max-threshold AF21 <= memory assigned to the queue
+
+   Note: This configuration tends to drop AF23 traffic before AF22 and
+   AF22 before AF21.  Many other AQM algorithms exist and are used; they
+   should be configured to achieve a similar result.
+
+4.8.  High-Throughput Data Service Class
+
+   The High-Throughput Data service class is RECOMMENDED for elastic
+   applications that require timely packet forwarding of variable rate
+   traffic sources and, more specifically, is configured to provide good
+   throughput for TCP longer-lived flows.  TCP [RFC1633] or a transport
+   with a consistent Congestion Avoidance Procedure [RFC2581] [RFC3782]
+   normally will drive as high a data rate as it can obtain over a long
+   period of time.  The FTP protocol is a common example, although one
+   cannot definitively say that all FTP transfers are moving data in
+   bulk.
+
+   The High-Throughput Data service class SHOULD use the Assured
+   Forwarding (AF) PHB, defined in [RFC2597].  This service class SHOULD
+   be configured to provide a minimum bandwidth assurance for AF11,
+   AF12, and AF13 marked packets to ensure that they are forwarded in a
+   timely manner.  The High-Throughput Data service class SHOULD be
+   configured to use a Rate Queuing system such as that defined in
+   Section 1.4.1.2 of this document.
+
+   The following applications SHOULD use the High-Throughput Data
+   service class:
+
+   o  Store and forward applications.
+   o  File transfer applications.
+   o  Email.
+   o  VPN service that supports two rates (committed information rate
+      and excess or peak information rate).
+
+
+
+Babiarz, et al.              Informational                     [Page 45]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   The following are traffic characteristics:
+
+   o  Variable size packets.
+   o  Variable packet emission rate.
+   o  Variable rate.
+   o  With packet bursts of TCP window size.
+   o  Source capable of reducing its transmission rate based on
+      detection of packet loss at the receiver or through explicit
+      congestion notification.
+
+   Applications or IP end points SHOULD pre-mark their packets with DSCP
+   values as shown below.  If the end point is not capable of setting
+   the DSCP value, then the router topologically closest to the end
+   point SHOULD perform Multifield (MF) Classification, as defined in
+   [RFC2475], and mark all packets as AF1x.  Note: In this case, the
+   two-rate, three-color marker will be configured to operate in Color-
+   Blind mode.
+
+   RECOMMENDED DSCP marking:
+
+   o  AF11 = up to specified rate "A".
+   o  AF12 = in excess of specified rate "A" but below specified rate
+      "B".
+   o  AF13 = in excess of specified rate "B".
+   o  Where "A" < "B".
+
+   RECOMMENDED conditioning performed at DiffServ network edge:
+
+   o  The two-rate, three-color marker SHOULD be configured to provide
+      the behavior as defined in trTCM [RFC2698].
+   o  If packets are marked by trusted sources or a previously trusted
+      DiffServ domain and the color marking is to be preserved, then the
+      two-rate, three-color marker SHOULD be configured to operate in
+      Color-Aware mode.
+   o  If the packet marking is not trusted or the color marking is not
+      to be preserved, then the two-rate, three-color marker SHOULD be
+      configured to operate in Color-Blind mode.
+
+   The fundamental service offered to "High-Throughput Data" traffic is
+   enhanced best-effort service with a specified minimum rate.  The
+   service SHOULD be engineered so that AF11 marked packet flows have
+   sufficient bandwidth in the network to provide assured delivery.  It
+   can be assumed that this class will consume any available bandwidth
+   and that packets traversing congested links may experience higher
+   queuing delays or packet loss.  Since the AF1x traffic is elastic and
+   responds dynamically to packet loss, Active Queue Management
+   [RFC2309] SHOULD be used primarily to control TCP flow rates at
+   congestion points by dropping packets from TCP flows that have higher
+
+
+
+Babiarz, et al.              Informational                     [Page 46]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   rates first.  The probability of loss of AF11 traffic MUST NOT exceed
+   the probability of loss of AF12 traffic, which in turn MUST NOT
+   exceed the probability of loss of AF13.  In such a case, if one
+   network customer is driving significant excess and another seeks to
+   use the link, any losses will be experienced by the high-rate user,
+   causing him to reduce his rate.  Explicit Congestion Notification
+   (ECN) [RFC3168] MAY also be used with Active Queue Management.
+
+   If RED [RFC2309] is used as an AQM algorithm, the min-threshold
+   specifies a target queue depth for each DSCP, and the max-threshold
+   specifies the queue depth above which all traffic with such a DSCP is
+   dropped or ECN marked.  Thus, in this service class, the following
+   inequality should hold in queue configurations:
+
+   o  min-threshold AF13 < max-threshold AF13
+   o  max-threshold AF13 <= min-threshold AF12
+   o  min-threshold AF12 < max-threshold AF12
+   o  max-threshold AF12 <= min-threshold AF11
+   o  min-threshold AF11 < max-threshold AF11
+   o  max-threshold AF11 <= memory assigned to the queue
+
+   Note: This configuration tends to drop AF13 traffic before AF12 and
+   AF12 before AF11.  Many other AQM algorithms exist and are used; they
+   should be configured to achieve a similar result.
+
+4.9.  Standard Service Class
+
+   The Standard service class is RECOMMENDED for traffic that has not
+   been classified into one of the other supported forwarding service
+   classes in the DiffServ network domain.  This service class provides
+   the Internet's "best-effort" forwarding behavior.  This service class
+   typically has minimum bandwidth guarantee.
+
+   The Standard service class MUST use the Default Forwarding (DF) PHB,
+   defined in [RFC2474], and SHOULD be configured to receive at least a
+   small percentage of forwarding resources as a guaranteed minimum.
+   This service class SHOULD be configured to use a Rate Queuing system
+   such as that defined in Section 1.4.1.2 of this document.
+
+   The following applications SHOULD use the Standard service class:
+
+   o  Network services, DNS, DHCP, BootP.
+   o  Any undifferentiated application/packet flow transported through
+      the DiffServ enabled network.
+
+   The following is a traffic characteristic:
+
+   o  Non-deterministic, mixture of everything.
+
+
+
+Babiarz, et al.              Informational                     [Page 47]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   The RECOMMENDED DSCP marking is DF (Default Forwarding) '000000'.
+
+   Network Edge Conditioning:
+
+      There is no requirement that conditioning of packet flows be
+      performed for this service class.
+
+   The fundamental service offered to the Standard service class is
+   best-effort service with active queue management to limit overall
+   delay.  Typical configurations SHOULD use random packet dropping to
+   implement Active Queue Management [RFC2309] or Explicit Congestion
+   Notification [RFC3168], and MAY impose a minimum or maximum rate on
+   the queue.
+
+   If RED [RFC2309] is used as an AQM algorithm, the min-threshold
+   specifies a target queue depth, and the max-threshold specifies the
+   queue depth above which all traffic is dropped or ECN marked.  Thus,
+   in this service class, the following inequality should hold in queue
+   configurations:
+
+   o  min-threshold DF < max-threshold DF
+   o  max-threshold DF <= memory assigned to the queue
+
+   Note: Many other AQM algorithms exist and are used; they should be
+   configured to achieve a similar result.
+
+4.10.  Low-Priority Data
+
+   The Low-Priority Data service class serves applications that run over
+   TCP [RFC0793] or a transport with consistent congestion avoidance
+   procedures [RFC2581] [RFC3782] and that the user is willing to accept
+   service without guarantees.  This service class is specified in
+   [RFC3662] and [QBSS].
+
+   The following applications MAY use the Low-Priority Data service
+   class:
+
+   o  Any TCP based-application/packet flow transported through the
+      DiffServ enabled network that does not require any bandwidth
+      assurances.
+
+   The following is a traffic characteristic:
+
+   o  Non-real-time and elastic.
+
+
+
+
+
+
+
+Babiarz, et al.              Informational                     [Page 48]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   Network Edge Conditioning:
+
+      There is no requirement that conditioning of packet flows be
+      performed for this service class.
+
+   The RECOMMENDED DSCP marking is CS1 (Class Selector 1).
+
+   The fundamental service offered to the Low-Priority Data service
+   class is best-effort service with zero bandwidth assurance.  By
+   placing it into a separate queue or class, it may be treated in a
+   manner consistent with a specific Service Level Agreement.
+
+   Typical configurations SHOULD use Explicit Congestion Notification
+   [RFC3168] or random loss to implement Active Queue Management
+   [RFC2309].
+
+   If RED [RFC2309] is used as an AQM algorithm, the min-threshold
+   specifies a target queue depth, and the max-threshold specifies the
+   queue depth above which all traffic is dropped or ECN marked.  Thus,
+   in this service class, the following inequality should hold in queue
+   configurations:
+
+   o  min-threshold CS1 < max-threshold CS1
+   o  max-threshold CS1 <= memory assigned to the queue
+
+   Note: Many other AQM algorithms exist and are used; they should be
+   configured to achieve a similar result.
+
+5.  Additional Information on Service Class Usage
+
+   In this section, we provide additional information on how some
+   specific applications should be configured to use the defined service
+   classes.
+
+5.1.  Mapping for Signaling
+
+   There are many different signaling protocols, ways that signaling is
+   used and performance requirements from applications that are
+   controlled by these protocols.  We believe that different signaling
+   protocols should use the service class that best meets the objectives
+   of application or service they control.  The following mapping is
+   recommended:
+
+   o  Peer-to-peer signaling using SIP/H.323 is marked with CS5 DSCP
+      (use Signaling service class).
+
+
+
+
+
+
+Babiarz, et al.              Informational                     [Page 49]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   o  Client-server signaling as used in many implementation for IP
+      telephony using H.248, MEGACO, MGCP, IP encapsulated ISDN, or
+      proprietary protocols is marked with CS5 DSCP (use Signaling
+      service class).
+   o  Signaling between call servers or soft-switches in carrier's
+      network using SIP, SIP-T, or IP encapsulated ISUP is marked with
+      CS5 DSCP (use Signaling service class).
+   o  RSVP signaling depends on the application.  If RSVP signaling is
+      "on-path" as used in IntServ, then it needs to be forwarded from
+      the same queue (service class) and marked with the same DSCP value
+      as application data that it is controlling.  This may also apply
+      to the "on-path" Next Steps in Signaling (NSIS) protocol.
+   o  If IGMP is used for multicast session control such as channel
+      changing in IPTV systems, then IGMP packets should be marked with
+      CS5 DSCP (use Signaling service class).  When IGMP is used only
+      for the normal multicast routing purpose, it should be marked with
+      CS6 DSCP (use Network Control service class).
+
+5.2.  Mapping for NTP
+
+   From tests that were performed, indications are that precise time
+   distribution requires a very low packet delay variation (jitter)
+   transport.  Therefore, we suggest that the following guidelines for
+   Network Time Protocol (NTP) be used:
+
+   o  When NTP is used for providing high-accuracy timing within an
+      administrator's (carrier's) network or to end users/clients, the
+      Telephony service class should be used, and NTP packets should be
+      marked with EF DSCP value.
+   o  For applications that require "wall clock" timing accuracy, the
+      Standard service class should be used, and packets should be
+      marked with DF DSCP.
+
+5.3.  VPN Service Mapping
+
+   "Differentiated Services and Tunnels" [RFC2983] considers the
+   interaction of DiffServ architecture with IP tunnels of various
+   forms.  Further to guidelines provided in RFC 2983, below are
+   additional guidelines for mapping service classes that are supported
+   in one part of the network into a VPN connection.  This discussion is
+   limited to VPNs that use DiffServ technology for traffic
+   differentiation.
+
+   o  The DSCP value(s) that is/are used to represent a PHB or a PHB
+      group should be the same for the networks at both ends of the VPN
+      tunnel, unless remarking of DSCP is done as ingress/egress
+      processing function of the tunnel.  DSCP marking needs to be
+      preserved end to end.
+
+
+
+Babiarz, et al.              Informational                     [Page 50]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   o  The VPN may be configured to support one or more service classes.
+      It is left up to the administrators of the two networks to agree
+      on the level of traffic differentiation that will be provided in
+      the network that supports VPN service.  Service classes are then
+      mapped into the supported VPN traffic forwarding behaviors that
+      meet the traffic characteristics and performance requirements of
+      the encapsulated service classes.
+   o  The traffic treatment in the network that is providing the VPN
+      service needs to be such that the encapsulated service class or
+      classes receive comparable behavior and performance in terms of
+      delay, jitter, and packet loss and that they are within the limits
+      of the service specified.
+   o  The DSCP value in the external header of the packet forwarded
+      through the network providing the VPN service may be different
+      from the DSCP value that is used end to end for service
+      differentiation in the end network.
+   o  The guidelines for aggregation of two or more service classes into
+      a single traffic forwarding treatment in the network that is
+      providing the VPN service is for further study.
+
+6.  Security Considerations
+
+   This document discusses policy and describes a common policy
+   configuration, for the use of a Differentiated Services Code Point by
+   transports and applications.  If implemented as described, it should
+   require that the network do nothing that the network has not already
+   allowed.  If that is the case, no new security issues should arise
+   from the use of such a policy.
+
+   It is possible for the policy to be applied incorrectly, or for a
+   wrong policy to be applied in the network for the defined service
+   class.  In that case, a policy issue exists that the network SHOULD
+   detect, assess, and deal with.  This is a known security issue in any
+   network dependent on policy-directed behavior.
+
+   A well-known flaw appears when bandwidth is reserved or enabled for a
+   service (for example, voice transport) and another service or an
+   attacking traffic stream uses it.  This possibility is inherent in
+   DiffServ technology, which depends on appropriate packet markings.
+   When bandwidth reservation or a priority queuing system is used in a
+   vulnerable network, the use of authentication and flow admission is
+   recommended.  To the author's knowledge, there is no known technical
+   way to respond to an unauthenticated data stream using service that
+   it is not intended to use, and such is the nature of the Internet.
+
+   The use of a service class by a user is not an issue when the SLA
+   between the user and the network permits him to use it, or to use it
+   up to a stated rate.  In such cases, simple policing is used in the
+
+
+
+Babiarz, et al.              Informational                     [Page 51]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   Differentiated Services Architecture.  Some service classes, such as
+   Network Control, are not permitted to be used by users at all; such
+   traffic should be dropped or remarked by ingress filters.  Where
+   service classes are available under the SLA only to an authenticated
+   user rather than to the entire population of users, authentication
+   and authorization services are required, such as those surveyed in
+   [AUTHMECH].
+
+7.  Acknowledgements
+
+   The authors thank the TSVWG reviewers, David Black, Brian E.
+   Carpenter, and Alan O'Neill for their review and input to this
+   document.
+
+   The authors acknowledge a great many inputs, most notably from Bruce
+   Davie, Dave Oran, Ralph Santitoro, Gary Kenward, Francois Audet,
+   Morgan Littlewood, Robert Milne, John Shuler, Nalin Mistry, Al
+   Morton, Mike Pierce, Ed Koehler Jr., Tim Rahrer, Fil Dickinson, Mike
+   Fidler, and Shane Amante.  Kimberly King, Joe Zebarth, and Alistair
+   Munroe each did a thorough proofreading, and the document is better
+   for their contributions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Babiarz, et al.              Informational                     [Page 52]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+8.  Appendix A
+
+8.1.  Explanation of Ring Clipping
+
+   The term "ring clipping" refers to those instances where the front
+   end of a ringing signal is altered because the bearer channel is not
+   made available in time to carry all the audible ringing signal.  This
+   condition may occur due to a race condition between when the tone
+   generator located in the circuit switch Exchange is turned on and
+   when the bearer path through the IP network is enabled.  To reduce
+   ring clipping from occurring, delay of signaling path needs to be
+   minimized.  Below is a more detailed explanation.
+
+   The bearer path setup delay target is defined as the ISUP Initial
+   Address Message (IAM) / Address Complete Message (ACM) round-trip
+   delay.  ISUP refers to ISDN User Part of Signaling System No. 7
+   (SS7), as defined by ITU-T.  This consists of the amount of time it
+   takes for the ISUP Initial Address Message (IAM) to leave the Transit
+   Exchange, travel through the SS7 network (including any applicable
+   STPs, or Signaling Transfer Points), and be processed by the End
+   Exchange thus generating the Address Complete Message (ACM) and for
+   the ACM to travel back through the SS7 network and return to the
+   Transit Exchange.  If the bearer path has not been set up within the
+   soft-switch media gateway and the IP network that is performing the
+   Transit Exchange function by the time the ACM is forwarded to the
+   originating End Exchange, the phenomenon known as ring clipping may
+   occur.  If ACM processing within the soft-switch media gateway and
+   delay through the IP network is excessive, it will delay the setup of
+   the bearer path, and therefore may cause clipping of the ring tone to
+   be heard.
+
+   The intra-exchange ISUP IAM signaling delay value should not exceed
+   240ms.  This may include soft-switch, media gateway, router, and
+   propagation delay on the inter-exchange data path.  This value
+   represents the threshold where ring clipping theoretically commences.
+   It is important to note that the 240ms delay objective as presented
+   is a maximum value.  Service administrators are free to choose
+   specific IAM delay values according to their own preferences (i.e.,
+   they may wish to set a very low mean delay objective for strategic
+   reasons to differentiate themselves from other providers).  In
+   summary, out of the 240-ms delay budget, 200ms is allocated as
+   cross-Exchange delay (soft-switch and media gateway) and 40ms for
+   network delay (queuing and distance).
+
+
+
+
+
+
+
+
+Babiarz, et al.              Informational                     [Page 53]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
+              1981.
+
+   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
+              793, September 1981.
+
+   [RFC1349]  Almquist, P., "Type of Service in the Internet Protocol
+              Suite", RFC 1349, July 1992.
+
+   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers", RFC
+              1812, June 1995.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2309]  Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
+              S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
+              Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
+              S., Wroclawski, J., and L. Zhang, "Recommendations on
+              Queue Management and Congestion Avoidance in the
+              Internet", RFC 2309, April 1998.
+
+   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
+              "Definition of the Differentiated Services Field (DS
+              Field) in the IPv4 and IPv6 Headers", RFC 2474, December
+              1998.
+
+   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
+              and W. Weiss, "An Architecture for Differentiated
+              Service", RFC 2475, December 1998.
+
+   [RFC2597]  Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
+              "Assured Forwarding PHB Group", RFC 2597, June 1999.
+
+   [RFC3246]  Davie, B., Charny, A., Bennet, J.C., Benson, K., Le
+              Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D.
+              Stiliadis, "An Expedited Forwarding PHB (Per-Hop
+              Behavior)", RFC 3246, March 2002.
+
+   [RFC3662]  Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
+              Per-Domain Behavior (PDB) for Differentiated Services",
+              RFC 3662, December 2003.
+
+
+
+
+
+Babiarz, et al.              Informational                     [Page 54]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+9.2.  Informative References
+
+   [AUTHMECH] Rescorla, E., "A Survey of Authentication Mechanisms",
+              Work in Progress, September 2005.
+
+   [QBSS]     "QBone Scavenger Service (QBSS) Definition", Internet2
+              Technical Report Proposed Service Definition, March 2001.
+
+   [RFC1633]  Braden, R., Clark, D., and S. Shenker, "Integrated
+              Services in the Internet Architecture: an Overview", RFC
+              1633, June 1994.
+
+   [RFC2205]  Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
+              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
+              Functional Specification", RFC 2205, September 1997.
+
+   [RFC2581]  Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
+              Control", RFC 2581, April 1999.
+
+   [RFC2697]  Heinanen, J. and R. Guerin, "A Single Rate Three Color
+              Marker", RFC 2697, September 1999.
+
+   [RFC2698]  Heinanen, J. and R. Guerin, "A Two Rate Three Color
+              Marker", RFC 2698, September 1999.
+
+   [RFC2963]  Bonaventure, O. and S. De Cnodder, "A Rate Adaptive Shaper
+              for Differentiated Services", RFC 2963, October 2000.
+
+   [RFC2983]  Black, D., "Differentiated Services and Tunnels", RFC
+              2983, October 2000.
+
+   [RFC2996]  Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996,
+              November 2000.
+
+   [RFC3086]  Nichols, K. and B. Carpenter, "Definition of
+              Differentiated Services Per Domain Behaviors and Rules for
+              their Specification", RFC 3086, April 2001.
+
+   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
+              of Explicit Congestion Notification (ECN) to IP", RFC
+              3168, September 2001.
+
+   [RFC3175]  Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
+              "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC
+              3175, September 2001.
+
+
+
+
+
+
+Babiarz, et al.              Informational                     [Page 55]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+   [RFC3290]  Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An
+              Informal Management Model for Diffserv Routers", RFC 3290,
+              May 2002.
+
+   [RFC3782]  Floyd, S., Henderson, T., and A. Gurtov, "The NewReno
+              Modification to TCP's Fast Recovery Algorithm", RFC 3782,
+              April 2004.
+
+Authors' Addresses
+
+   Jozef Babiarz
+   Nortel Networks
+   3500 Carling Avenue
+   Ottawa, Ont.  K2H 8E9
+   Canada
+
+   Phone: +1-613-763-6098
+   Fax:   +1-613-765-7462
+   EMail: babiarz@nortel.com
+
+
+   Kwok Ho Chan
+   Nortel Networks
+   600 Technology Park Drive
+   Billerica, MA  01821
+   US
+
+   Phone: +1-978-288-8175
+   Fax:   +1-978-288-8700
+   EMail: khchan@nortel.com
+
+
+   Fred Baker
+   Cisco Systems
+   1121 Via Del Rey
+   Santa Barbara, CA  93117
+   US
+
+   Phone: +1-408-526-4257
+   Fax:   +1-413-473-2403
+   EMail: fred@cisco.com
+
+
+
+
+
+
+
+
+
+
+Babiarz, et al.              Informational                     [Page 56]
+
+RFC 4594        Guidelines for DiffServ Service Classes      August 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Babiarz, et al.              Informational                     [Page 57]
+