tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4594

 Errata 
Informational
Pages: 57
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: TSVWG

Configuration Guidelines for DiffServ Service Classes

Part 1 of 4, p. 1 to 11
None       Next RFC Part

Updated by:    5865


Top       ToC       Page 1 
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.

Top       Page 2 
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

Top      ToC       Page 3 
   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

Top      ToC       Page 4 
   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.

Top      ToC       Page 5 
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.

Top      ToC       Page 6 
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

Top      ToC       Page 7 
   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.

Top      ToC       Page 8 
   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.

Top      ToC       Page 9 
   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.

Top      ToC       Page 10 
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'.

Top      ToC       Page 11 
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.



(page 11 continued on part 2)

Next RFC Part