[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

   Internet Draft                                            Fred Baker
   draft-baker-diffserv-basic-classes-01.txt                      Cisco
   Expires: April 2004                                    Jozef Babiarz
                                                           Kwok Ho Chan
                                                        Nortel Networks
                                                           October 2003

                 Configuration Guidelines for DiffServ
                            Service Classes


Status of this Memo
     This document is an Internet-Draft and is in full conformance with
     all provisions of Section 10 of RFC2026.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups. Note that
     other groups may also distribute working documents as Internet-
     Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet-Drafts
     as reference material or to cite them other than as "work in
     progress."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

Copyright Notice

     Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

   This paper summarizes the recommended correlation between service
   classes and their usage, with references to their corresponding
   recommended Differentiated Service Code Points (DSCP), traffic
   conditioners, Per-Hop Behaviors (PHB) and Active Queue Management
   (AQM) mechanisms. There is no intrinsic requirement that particular
   DSCPs, traffic conditioner PHBs and AQM be used for a certain
   service class, but as a policy it is useful that they be applied
   consistently across the network.

Conventions used in this document
     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
     NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
     in this document are to be interpreted as described in [RFC-2119].




Babiarz et al.            Expires April 2004                  [Page 1]


Internet Draft          DiffServ-Basic-Classes            October 2003





Table of Contents


   1. Introduction....................................................3
   1.1 Expected use in the Network....................................3
   1.2 Key Differentiated Services Concepts...........................4
   1.2.1 Queuing......................................................4
   1.2.1.1 Priority Queuing...........................................4
   1.2.1.2 Rate Queuing...............................................4
   1.2.2 Active Queue Management......................................5
   1.2.3 Traffic Conditioning.........................................5
   1.2.4 Differentiated Services Code Point (DSCP)....................6
   1.2.5 Per-Hop Behavior (PHB).......................................6
   1.3 Key Service Concepts...........................................6
   1.3.1 Default Forwarding (DF)......................................7
   1.3.2 Assured Forwarding (AF)......................................8
   1.3.3 Expedited Forwarding (EF)....................................8
   1.3.4 Class Selector (CS)..........................................9
   1.3.5 Admission Control............................................9
   1.3.6 Service Differentiation.....................................10
   2. Traffic Categories and Service Classes.........................10
   3. Network Control Traffic Category...............................14
   3.1 Administration Service Class..................................14
   3.2 Network Control Service Class.................................15
   4. User Traffic Categories........................................16
   4.1 Interactive Traffic Category..................................17
   4.1.1 Telephony Service Class.....................................17
   4.1.2 Multimedia Conferencing Service Class.......................20
   4.2 Responsive Traffic Category...................................22
   4.2.1 Multimedia Streaming Service Class..........................22
   4.2.2 Low Latency Data Service Class..............................24
   4.3 Timely Traffic Category.......................................26
   4.3.1 High Throughput Data Service Class..........................26
   4.3.2 Standard Service Class......................................28
   4.4 Non-Critical Traffic Category.................................29
   4.4.1 Low Priority Data Service Class.............................29
   5. Mapping Applications to Service Classes........................29
   6. Security Considerations........................................30
   7. Acknowledgements...............................................31
   8. Normative References...........................................31
   9. Informative References.........................................32
   10. Author's Address..............................................33
   11. Full Copyright Statement......................................34







Babiarz et al.            Expires April 2004                  [Page 2]


Internet Draft          DiffServ-Basic-Classes            October 2003


1. Introduction

   This paper summarizes the recommended correlation between service
   classes and their usage, with references to their corresponding
   recommended Differentiated Service Code Points (DSCP), traffic
   conditioners, Per-Hop Behaviors (PHB) and Active Queue Management
   (AQM) mechanisms. There is no intrinsic requirement that particular
   DSCPs, traffic conditioner PHBs and AQM be used for a certain
   service class, but as a policy it is useful that they be applied
   consistently across the network.

   Service classes are defined, 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 characteristic and
   performance requirements into the same service class. With this
   approach, a limited set of service classes is required. For
   completeness, we have defined nine different service classes, two
   for network operation/administration and seven for user/subscriber
   applications/services. However, we expect that network
   administrators will selectively choose the service classes that are
   required in their network based on their needs.


1.1 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.

     - 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.

     - In access networks, the state is often different. This may be
       because throughput rates are artificially limited, or because of
       access network design trade-offs.

     - Other characteristics, such as database design on web servers
       (which 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 which finds itself
   congested.



Babiarz et al.            Expires April 2004                  [Page 3]


Internet Draft          DiffServ-Basic-Classes            October 2003

1.2 Key Differentiated Services Concepts

   The reader must be familiar with the principles of the
   Differentiated Services Architecture [8]. However, we recapitulate
   key concepts here so save searching.


1.2.1 Queuing


   A queue is a data structure that holds traffic that is awaiting
   transmission. The traffic 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; in some of these,
   it is more natural to discuss "service classes in a queuing system"
   rather than "a set of queues and a scheduler". In the literature, as
   a result, the concepts are used somewhat interchangeably.

   A simple model of a queuing system, however, is a set of data
   structures for packet data, which we will call queues or service
   classes and a mechanism for selecting the next packet from among
   them, which we call a scheduler.


1.2.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, but which 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 - it 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 which has that requirement.

   A priority queue or queuing system needs to support rate and burst
   size control mechanism(s) to provide starvation avoidance of lower
   priority queues.


1.2.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

Babiarz et al.            Expires April 2004                  [Page 4]


Internet Draft          DiffServ-Basic-Classes            October 2003

   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 WFQ[27][26] or WRR[28], the
   delay that a packet in any given queue will experience is dependant
   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 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 to be not 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.2.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 [25], in which 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 the mean queue depth (and therefore delay) should normally
   approximate the minimum threshold.

   A variation of the algorithm is applied in Assured Forwarding [11],
   in which 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 which exceeds a stated rate at ingress is more
   likely to be dropped or marked than traffic which was within its
   contracted rate.


1.2.3 Traffic Conditioning


   Additionally, 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 [23]. This may be
   used to bias feedback loops, such as is done in Assured Forwarding
   [11], or to limit the amount of traffic in a system, as is done in
   Expedited Forwarding [19]. Such measurement procedures are

Babiarz et al.            Expires April 2004                  [Page 5]


Internet Draft          DiffServ-Basic-Classes            October 2003

   collectively referred to as "traffic conditioners".  Two traffic
   conditioners that are use in deployment of differentiated services
   that use Assured Forwarding are the Two Rate Three Color Marker
   (trTCM) [18] and the Single Rate Three Color Marker (srTCM) [17].

   Two Rate Three Color Marker:
     The Two Rate Three Color Marker (trTCM) meters an IP packet stream
     and marks its packets based on two rates, Peak Information Rate
     (PIR) and Committed Information Rate (CIR), and their associated
     burst sizes to be green, yellow, or red.  A packet is marked red if
     it exceeds the PIR.  Otherwise it is marked either yellow or green
     depending on whether it exceeds or doesn't exceed the CIR. The
     trTCM is use to enforce committed rate separately from Peak
     Information Rate.

   Single Rate Three Color Marker:
     The Single Rate Three Color Marker (srTCM) meters an IP packet
     stream and marks its packets green, yellow, or red.  Marking is
     based on a Committed Information Rate (CIR) and two associated
     burst sizes, a Committed Burst Size (CBS) and an Excess Burst Size
     (EBS).  A packet is marked green if it doesn't exceed the CBS,
     yellow if it does exceed the CBS, but not the EBS and red
     otherwise.  The srTCM is used to enforce the committed rate and
     burst length.


1.2.4 Differentiated Services Code Point (DSCP)

   The DSCP is a number in the range 0..63, which 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
   half of them are available for local definition.


1.2.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 specify what PHB
   should be applied to them.


1.3 Key Service Concepts

   While Differentiated Services is a general architecture that may be
   used to implement a variety of services, three fundamental services
   have been defined and characterized for general use. These are basic
   service for elastic traffic, the Assured Forwarding service, and the
   Expedited Forwarding service for real-time (inelastic) traffic.



Babiarz et al.            Expires April 2004                  [Page 6]


Internet Draft          DiffServ-Basic-Classes            October 2003

   The terms "elastic" and "real-time" are defined in RFC 1633[2]
   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 RFC
   2475[8] should be reviewed to understand the data plane architecture
   used in today's Internet.

   The definition of "service class" is, a description of the overall
   treatment of (or a subset of) a customer's traffic across a
   particular domain, across a set of interconnected DiffServ Domain
   (DS) domains, or end-to-end. Service descriptions are covered by
   administrative policy and services are constructed by applying
   traffic conditioning to create behavior aggregates which experience
   a known PHB at each node within the DS domain. A service class
   provides the specified end-to-end behaviors in the network which
   will support one or more applications or a set of applications that
   have similar traffic characteristics and performance requirements.
   This concept allows grouping of applications of similar traffic
   characteristics and performance requirements into a common
   forwarding discipline called a "service class" that provides
   consistent behavior in the administered network. (Service class
   definition originates from RFC 2474 [7] section 2 definition of a
   service)


1.3.1 Default Forwarding (DF)

   The basic services applied to any class of traffic are those
   described in RFC 2474[7] and RFC 2309[6]. Best Effort Service may be
   summarized as "I will accept your packets", with no further
   guarantees. 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 is expected to be "elastic" in
   nature. By this, we mean that 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 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. The
   interesting thing is that by giving that queue a higher minimum rate
   than its measured arrival rate, we can effectively limit the
   deleterious effects of congestion on a given class of traffic,
   transferring them to another class that is perhaps better able to
   absorb the impact or is considered to be of lower value to the
   network administration. So, for example, if it is important to
   service database exchange or transaction traffic in a timely



Babiarz et al.            Expires April 2004                  [Page 7]


Internet Draft          DiffServ-Basic-Classes            October 2003

   fashion, isolating the traffic into a queue and giving it a
   relatively high minimum rate will accomplish that.

   Scavenger, or less than best effort, service can also be provided,
   for applications with congestion avoidance capabilities and is
   considered to be of lower value to the network administration then
   best effort traffic.


1.3.2 Assured Forwarding (AF)

   The Assured Forwarding RFC 2597[11] service is explicitly modeled on
   Frame Relay's DE flag or ATM's CLP capability, and is intended for
   networks which offer average-rate 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 classes, multiple DSCP values are provided (two or three,
   perhaps more using local values) to identify the traffic, a common
   queue or class 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 to occasionally use more capacity than their
   contract stipulates, perhaps up to some bound. However, if traffic
   must be lost or marked to manage the queue, this excess traffic will
   be marked or lost first.


1.3.3 Expedited Forwarding (EF)


   Expedited Forwarding RFC 3246[19] was originally proposed as a way
   to implement a virtual wire, and can be used in such a manner. It is
   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 must police traffic at
   various points to ensure that the design of a queue is not over-run,
   and then the traffic must 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.

Babiarz et al.            Expires April 2004                  [Page 8]


Internet Draft          DiffServ-Basic-Classes            October 2003

1.3.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 RFC 2474 [7] 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 [RFC 1812]), 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 RFC 2474 Sec. 4.2.2.2.

   No attempt is made to maintain backward compatibility with the "DTR"
   or TOS bits of the IPv4 TOS octet, as defined in [RFC 791].

   A DS-compliant network can be deployed with a set of one or more
   Class Selector Compliant PHB groups.  As well, 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'.


1.3.5 Admission Control


   Admission control including refusal when policy thresholds are
   crossed, can assure high quality communication by ensuring the
   availability of bandwidth to carry a load. Inelastic real-time flows
   like VoIP (telephony) or video conferencing services can benefit
   from use of admission control mechanism, as generally the telephony
   service is configured with over subscription, meaning that some
   user(s) 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, RSVP, etc. to negotiate
   admittance and usage of network transport capabilites. 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. Since RTP voice does not respond to loss
   or marking in any substantive way, the network must 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[4][13]. However, there
   is concern with the Scalability [5] of this solution in large
   networks and Aggregation [15] of sessions is considered to be a
   requirement.

Babiarz et al.            Expires April 2004                  [Page 9]


Internet Draft          DiffServ-Basic-Classes            October 2003

1.3.6 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 to provide the appropriated 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 one service class and therefore
   forwarded by single queue in a router. Also we provide a method for
   different application (flows) within a service class to have unique
   DSCP marking so that different conditioning and policing polices may
   be used for different flows, through the use of Class Selector (CS)
   codepoints or locally defined DSCP (EXP/LU) values and associating
   them with the standardized PHBs. 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 new traffic type is added to the network.


2. Traffic Categories and Service Classes


   This document divides traffic into five categories, one for network
   control and four for user/subscriber traffic. The term "user" and
   "subscriber" are used interchangeable in this document. Network
   control traffic can further be divided into two service classes,
   mainly flows that are critical, require lower delay or higher
   probability of being serviced and normal network control flows.
   User/subscriber traffic is broken down into four user traffic
   categories, interactive, responsive, timely and non-critical as
   defined by ITU-T Recommendation G.1010.  These four user traffic
   categories can further be subdivided into one or more different
   service classes within each traffic category to provide further
   behavior differentiation. End-to-end performance requirements for
   these traffic categories and service classes are further defined in
   ITU-T Recommendation Y.1541, Y.1540 and G.1010. Additionally,
   network administrators may choose to define other service classes.

   The service classes define the required treatment for the traffic in
   order to meet user, application or network expectations.  Section 3
   in this document 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 of their service
   classes.  Note that the application types are only examples and are
   not meant to be all-inclusive.  Also it should be noted 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

Babiarz et al.            Expires April 2004                 [Page 10]


Internet Draft          DiffServ-Basic-Classes            October 2003

   particular application types they support. Network administrators
   may choose to assign different service class names, to the service
   classes that they will support.  Table 1 below defines the
   relationship between service classes and DS codepoint(s) assignment
   with application examples.

    ------------------------------------------------------------------
   |   Service     |  DSCP   |    DSCP     |       Application        |
   |  Class name   |  name   |    value    |        Examples          |
   |===============+=========+=============+==========================|
   |Administration |  CS7    |   111000    | Heartbeats, SSH, Telnet  |
   |---------------+---------+-------------+--------------------------|
   |Network Control|  CS6    |   110000    | Network routing          |
   |---------------+---------+-------------+--------------------------|
   | Telephony     | EF,CS5  |101010,101000| IP Telephony             |
   |---------------+---------+-------------+--------------------------|
   | Multimedia    |AF41,AF42|100010,100100| Video conferencing       |
   | Conferencing  |  AF43   |100110       | Interactive gaming       |
   |---------------+---------+-------------+--------------------------|
   | Multimedia    |AF31,AF32|011010,011100|Broadcast TV, Pay per view|
   | Streaming     |AF33, CS4|011110,100000|Video surveillance        |
   |---------------+---------+-------------+--------------------------|
   | Low Latency   |AF21,AF22|010010,010100|Client/server transactions|
   |   Data        |AF23, CS3|010110,011000|peer-to-peer signaling    |
   |---------------+---------+-------------+--------------------------|
   |High Throughput|AF11,AF12|001010,001100|Store&forward applications|
   |    Data       |AF13, CS2|001110,010000|Non-critcal OAM&P         |
   |---------------+---------+-------------+--------------------------|
   |    Standard   | DF,(CS0)|   000000    | Undifferentiated         |
   |               |         |             | applications             |
   |---------------+---------+-------------+--------------------------|
   | Low Priority  | CS1     |   001000    | Any flow that has no BW  |
   |     Data      |         |             | assurance                |
    ------------------------------------------------------------------
                 Table 1: DSCP to Service Class Mapping

     Note: The Class Selector 2,3 and 4 codepoints are aliases of AF11,
     AF21 and AF31 codepoints respectfully. Class Selector 5 codepoint
     is alias of EF codepoint. Default Forwarding and Class Selector 0
     provide equivalent behavior and use the same DS codepoint.

     Table 2 provides a summary of DiffServ QoS mechanisms used for the
     nine different service classes that are further defined in Section
     3 and 4 of this document. Based on what applications/service that
     need to be differentiation, network administrators can choose the
     service class(es) that needs to be supported in their network.

     Example 1:
     A network administrator determines that they need in their network
     to provide three different levels of network performance (quality
     of service) for the services that they will be offering to their
     customers. They need to enable their network to provide reliable


Babiarz et al.            Expires April 2004                 [Page 11]


Internet Draft          DiffServ-Basic-Classes            October 2003

     VoIP (telephony) service, equivalent to PSTN. A low delay assured
     bandwidth data service that customers will purchase plus access to
     The Internet for basic connectivity. In this example, the network
     administrator's needs are addressed with the deployment of the
     following service classes:
     - Standard service class for all traffic that will receive normal
       (undifferentiated) forwarding treatment through their network.
     - Telephony service class for VoIP (telephony) traffic.
     - Low Latency Data service class for the differentiated data
       service.
     - Network Control service class for routing and control traffic
       that is needed for reliable operation of the provider's network.

     Example 2:
     A network administrator determines that they need to support two
     service classes for control and administration of their network
     plus six levels of service differentiation for user traffic use the
     following service classes:
     - Administration
     - Network Control
     - Standard
     - Telephony
     - Low Latency Data
     - High Throughput Data
     - Multimedia Conferencing
     - Multimedia Streaming

     Example 3:
     An enterprise network administrator determines that thy need to
     provide seven levels of service differentiation for user traffic
     plus one for running of their network. They would configure their
     network to support the following service classes:
     - Network Control
     - Telephony
     - Multimedia Conferencing
     - Multimedia Streaming
     - Low Latency Data
     - High Throughput Data
     - Standard
     - Low Priority Data

     It is expected that network administrators will choose the service
     classes that they will support based on their need. Start off with
     two or three service classes for user traffic and add others as the
     need arises.









Babiarz et al.            Expires April 2004                 [Page 12]


Internet Draft          DiffServ-Basic-Classes            October 2003

    ------------------------------------------------------------------
   |  Service      | DSCP | Conditioning at   |   PHB   | Queuing| AQM|
   |   Class       |      |    DS Edge        |Reference|        |    |
   |===============+======+===================+=========+========+====|
   |Administration | CS7  |Police using sr+bs | RFC2474 |Priority| No |
   |---------------+------+-------------------+---------+--------+----|
   |Network Control| CS6  |Police using sr+bs | RFC2474 |  Rate  | No |
   |---------------+------+-------------------+---------+--------+----|
   | Telephony     |EF,CS5|Police using sr+bs | RFC3246 |Priority| No |
   |---------------+------+-------------------+---------+--------+----|
   |               | AF41 |                   |         |        | Yes|
   | Multimedia    | AF42 |  Using trTCM      | RFC2597 |  Rate  | per|
   | Conferencing  | AF43 |   (RFC2698)       |         |        |DSCP|
   |---------------+------+-------------------+---------+--------+----|
   |               | AF31 | Police using sr+bs|         |        |    |
   |               |------+-------------------|         |        | Yes|
   | Multimedia    | AF32 | Police sum using  |         |  Rate  | per|
   | Streaming     | AF33 |      sr+bs        | RFC2597 |        |DSCP|
   |               |------+-------------------|         |        |----|
   |               | CS4  |Police using sr+bs |         |        | No |
   |---------------+------+-------------------+---------+--------+----|
   |               | AF21 |                   |         |        | Yes|
   |    Low        | AF22 |  Using srTCM      |         |        | per|
   |   Latency     | AF23 |   (RFC 2697)      | RFC2597 |  Rate  |DSCP|
   |    Data       |------+-------------------|         |        |----|
   |               | CS3  |Police using sr+bs |         |        | No |
   |---------------+------+-------------------+---------+--------+----|
   |               | AF11 |                   |         |        | Yes|
   |    High       | AF12 |  Using srTCM      |         |        | per|
   |  Throughput   | AF13 |   (RFC 2697)      | RFC2597 |  Rate  |DSCP|
   |    Data       |------+-------------------|         |        |----|
   |               | CS2  |Police using sr+bs |         |        | No |
   |---------------+------+-------------------+---------+--------+----|
   |   Standard    | DF   | Not applicable    | RFC2474 |  Rate  | Yes|
   |---------------+------+-------------------+---------+--------+----|
   | Low Priority  | CS1  | Not applicable    | pdb-le  |  Rate  | Yes|
   |     Data      |      |                   |  -draft |        |    |
    ------------------------------------------------------------------
     Table 2: Summary of QoS Mechanisms used for each Service Class

     Note: 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.

     Note: "sr+bs" represents a policing mechanism that provides single
     rate with burst size control.








Babiarz et al.            Expires April 2004                 [Page 13]


Internet Draft          DiffServ-Basic-Classes            October 2003

3. Network Control Traffic Category

   Network control traffic is defined as packet flows that are
   essential for stable operation of the administered network as well
   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 administering, controlling or managing the network segments and
   the services that are provided in that network segment. A network
   administrator may choose to split the network control traffic into
   two service classes i.e., Administration and Network Control to
   provide two different forwarding treatments or just support one
   forwarding treatment for all network control flows.


3.1 Administration Service Class


   The Administration service class is intended to be used for control
   traffic that is within a single administrative network domain. If
   such traffic does not get through, the administered network domain
   may not function properly. Example of such type of traffic is
   heartbeats between core network switches/routers. Such heartbeats
   are used to determine if the next hop is reachable. If no heartbeat
   is received within a specified time interval, then the sending
   router assumes that the particular link or next hop node is
   unreachable on a particular interface and subsequently reroutes the
   traffic to a backup interface that can reach the next hop node.
   This reroute is typically done in a time interval much shorter than
   the time it would take for the routing protocol to determine that
   the next hop node is unreachable.

   The Administration service class uses the DiffServ Class Selector
   (CS) PHB defined in RFC 2474 [7] and should be configured to receive
   sufficed forwarding resources so that all packets are forwarded
   quickly.  The Administration service class should be configured to
   use Priority Queuing system such as defined in Section 1.2.1.1 of
   this document.

   The following protocols and application should use the
   Administration service class:
     - Network administrator's telnet sessions from secure and trusted
       terminals, Secure Shell (SSH)
     - Protocol(s) that are transmitted between nodes within the
       administered network for detecting of link and nodal failures
     - Used for critical control traffic within an administrative
       domain
     - May be used for any control traffic that is forwarded within the
       administered network domain such as NTP information that
       requires very low delay variation (jitter)
     - User traffic must not be mapped into this service class

Babiarz et al.            Expires April 2004                 [Page 14]


Internet Draft          DiffServ-Basic-Classes            October 2003

     - Inter-network domain (across peering points) control traffic
       should not be mapped into this service class

   Traffic characteristics of packet flows in the Administration
   service class:
     - Mostly messages between routers and network servers
     - Typically small packet sizes, one packet at a time
     - Packets require immediate forwarding
     - No user-to-user traffic is allowed to use this service class

   Recommended DSCP marking is CS7 (Class Selector 7)

   Network edge conditioning:
     - Drop or remark CS7 marked packets at ingress to DiffServ network
       domain.
     - Depending on policy within the administered network, CS7 marked
       packets may be dropped or remarked to CS6 at egress of DiffServ
       network or across peering points.


3.2 Network Control Service Class

   The Network Control service class is used for transmitting packets
   between network devices (routers, servers, etc.) that require
   control information to be exchanged between different administrative
   domains (across a peering point) and for non-critical network
   control information exchange within one administrative domain.
   Traffic transmitted in this service class is very important as it
   keeps the network operational and needs to be forwarded in a timely
   manner.

   The Network Control service class uses the DiffServ Class Selector
   (CS) PHB defined in RFC 2474 [7]. This service class is 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 Control service class
   should be configured to use Rate Queuing system such as defined in
   Section 1.2.1.2 of this document.

   The following protocols and applications should use the Network
   Control service class:
     - Routing packet flows, OSPF, BGP, ISIS, RIP
     - Policy management flows between nodes in the network, COPS,
       RSVP-TE, etc.
     - SIP-T signaling between high capacity telephony call servers or
       soft switches.  Such high capacity devices may control thousands
       of telephony (VoIP) calls.
     - Network services, DNS, DHCP, BootP, high priority OAM (SNMP)
       like alarms, etc.



Babiarz et al.            Expires April 2004                 [Page 15]


Internet Draft          DiffServ-Basic-Classes            October 2003

     - Used for control information exchange within and between
       different administrative domains across a peering point where
       SLAs are in place.
     - In 3GPP wireless solutions, used to transport UMTS
       signaling/control information between wireless nodes
     - User traffic must not be mapped into this service class

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

   Recommended DSCP marking is CS6 (Class Selector 6)

   Network edge conditioning:
     - At peering points (between two DiffServ networks) where SLAs are
       in place, CS6 marked packets are policed 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.
     - CS6 marked packet flows from untrusted sources (end user
       devices) are dropped or remarked at ingress to DiffServ network.
       Packets from users are not permitted access to the Network
       Control or Administration service classes.

   If Administration service class is not supported, then the Network
   Control service class is used for both normal network control
   traffic and network administration traffic defined in this document
   and packets marked with CS7 DSCP receive the same forwarding
   treatment as CS6 marked packets.


4. User Traffic Categories

   User traffic is divided into four different categories, namely,
   interactive, responsive and timely. 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 is needed. Responsive traffic
   is typically between a human and a server but also can 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 normal between servers/machines where delivery may be
   delay for period of time. The Four traffic categories follow
   methodology defined by ITU-T Recommendation Y.1541 and G.1010.

   Network administrators can categorize their applications based on
   the type of behavior that they require.  Table 1 provides some


Babiarz et al.            Expires April 2004                 [Page 16]


Internet Draft          DiffServ-Basic-Classes            October 2003

   common applications and the forwarding service class that best
   supports them based on their performance requirements.


   In summary:
     - Telephony service class is best suited for applications that
       require very low delay and are of constant rate, such as IP
       telephony (VoIP) and circuit emulation over IP applications.
     - Multimedia Conferencing service class is best suited for
       applications that require very low delay but are of variable
       rate, such as video conferencing and interactive gaming.
     - Multimedia Streaming service class is best suited for streaming
       media applications such as broadcast TV, pay-per-view, video
       surveillance and security, etc.
     - Low Latency Data service class is best suited for interactive
       client / server or client-to-client applications such as web-
       based ordering, EPR application, peer-to-peer signaling, etc.
     - High Throughput Data service class is best suited for store and
       forward applications such as FTP, billing record transfer, etc.
     - Standard service class is for traffic that has not bean
       identified as requiring differentiated treatment and is normally
       referred as best effort.
     - Low Priority Data service class is intended for packet flows
       where bandwidth assurance is not required.

   Note, a network administrator may choose to support all or subsets
   of the defined service classes and provide service differentiation
   only to the applications/service that are mapped into them.



4.1 Interactive Traffic Category

   Interactive traffic category can be further split into two service
   classes, Telephony and Multimedia Conferencing to provide
   differentiation based on the different behavior of source traffic
   being forwarded.


4.1.1 Telephony Service Class


   Used for applications that require real-time, low delay, very low
   packet loss for relatively constant-rate traffic sources (inelastic
   traffic sources). This forwarding class is used predominantly for IP
   telephony services and provides the low latency, jitter and loss
   required.

   The fundamental service offered to traffic in the Telephony service
   class is a higher priority service than best-effort up to a
   specified upper bound with low delay and very low packet loss.
   Operation is in some respect similar to an ATM CBR service, which
   has guaranteed bandwidth and if it stays within the negotiated rate

Babiarz et al.            Expires April 2004                 [Page 17]


Internet Draft          DiffServ-Basic-Classes            October 2003

   it 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 has verified that the newly admitted data rates will be
   within the capacity of the Telephony service class forwarding
   capability in the network that it will use. For VoIP (telephony)
   service, the common approach is to use call admission control
   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
   RTP telephony flows do not respond to loss or substantial delay in
   any substantive way, the Telephony service class should forward
   packet as soon as possible.

   The Telephony service class uses Expedited Forwarding (EF) PHB as
   defined in RFC 3246 [19] and must be configured to receive
   guaranteed forwarding resources so that all packets are forwarded
   quickly. The Telephony service class should be configured to use
   Priority Queuing system such as defined in Section 1.2.1.1 of this
   document.

   Target applications for Telephony service class:
     - VoIP (G.711, G.729 and other codecs)
     - Telephony (trunk and/or stimulus) signaling between end device
       (terminals/gateways) and the call server (H.248, MEGACO)
     - Lawful Intercept
     - Voice-band data over IP (modem, fax)
     - T.38 fax over IP
     - Circuit emulation over IP, virtual wire, etc.
     - In wireless 3GPP applications, used to forward traffic that is
       mapped into the UMTS Conversational Traffic Class

   Traffic characteristics:
     - Mostly fixed size packets for VoIP (60 or 70 or 120 or 200 bytes
       in size)
     - Packet emitted at constant time intervals
     - Admission control of new flows is provided by telephony call
       server, media gateway, gatekeeper, edge router or access node
       that provides "middlebox" function.

   Recommended DSCP marking EF for the following applications:
     - VoIP (G.711, G.729 and other codecs)
     - Lawful Intercept
     - Voice-band data over IP (modem)
     - Circuit emulation over IP, virtual wire, etc.
     - Conversational UMTS Traffic Class

   Recommended DSCP marking CS5 for the following applications:

Babiarz et al.            Expires April 2004                 [Page 18]


Internet Draft          DiffServ-Basic-Classes            October 2003

     - Telephony (trunk and/or stimulus) signaling between end device
       (terminals/gateways) and the call server (H.248, MEGACO)
     - T.38 fax over IP

   Both EF and CS5 DS codepoints are mapped into the Telephony service
   classes and used the Expedited Forwarding (EF) PHB. The CS5 DS
   codepoint is aliased to the EF codepoint and packets marked with CS5
   are forwarded using the EF PHB.

   Network Edge Conditioning:
     - Packet flows from untrusted sources (end user devices) must be
       policed at ingress to DiffServ network using single rate with
       burst size token bucket policer to ensure that the telephony
       traffic stays within its negotiated bounds.
     - Packet flows from trusted sources (media gateways inside
       administered network) do not require policing.
     - Policing of Telephony packet flows across peering points where
       SLA is in place is not required as telephony traffic will be
       controlled by admission control mechanism between peering
       points.

   Note: On low speed links (typically access links below 1Mbps), in
   the attempt to minimize jitter/delay, it is recommended that
   packetized audio streams are separated from processed telephony data
   information flows like T.38 fax and telephony signaling and
   forwarded using less stringent from delay/jitter perspective service
   class. PCM voice when compressed produces very small packets i.e. 60
   bytes in size were T.38 fax and signaling packets can be much
   bigger. The serialization delay, therefore delay/jitter for the
   larger T.38 fax and signaling packets can be significantly bigger
   over low speed links then for 60 byte voice packets. For this reason
   it is recommended that packetized voice packets receive a higher
   priority forwarding treatment then the less sensitive from
   delay/jitter perspective T.38 fax and telephony signaling packets.
   PCM audio streams (voice) have a strict end-to-end delay constrain
   and should use Priority Queuing system where as T.38 fax or
   telephony signaling have a more liberal jitter/delay constrain and
   should use Rate Queuing system on access links below 1 Mbps.

   On higher speed links the difference in serialization delay is very
   small, therefore both types of telephony packet flows are aggregated
   in to a single forwarding service class to simplify network
   engineering and use Priority Queuing system. As well, the forwarding
   of voice packets and signaling packets with the same very low delay
   forwarding service class minimizes delay as well as the difference
   in delay between signaling and bearer path, therefore virtually
   eliminating speech clipping and ring-clipping problems at start of
   call when interfacing to PSTN.






Babiarz et al.            Expires April 2004                 [Page 19]


Internet Draft          DiffServ-Basic-Classes            October 2003

4.1.2 Multimedia Conferencing Service Class

   Used for applications that requires real-time and low delay for
   variable rate elastic traffic source. The traffic sources
   (applications) in this traffic class have the capability to change
   their emitting rate based on feedback received from the receiving
   end. Detection of packet loss by the receiver is sent using the
   applications control stream to the transmitter as an indication of
   possible congestion. The transmitter based on pre-configured
   encoding rates (or transmitting rates) selects a lower rate for
   transmission.

   Typical video conferencing configurations negotiate the setup of
   multimedia session using protocols such as H.323 or SIP.  When a
   user/end-point has been authorized to start a multimedia session the
   admission procedure has verified that the newly admitted data rates
   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 needs to be engineered to control traffic load for this
   service.

   The Multimedia Conferencing service class uses the Assured
   Forwarding (AF) PHB defined in RFC 2597 [11]. This service class is
   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 Rate Queuing
   system such as defined in Section 1.2.1.2 of this document.

   Target application for Multimedia Conferencing service class:
     - Video conferencing (interactive video)
     - Interactive gaming
     - Server to server data transfer requiring very low delay
     - IP VPN service that specifies two rates and mean network delay
       that is slightly longer then network propagation delay.
       Interactive, time critical and mission critical application
       maybe encapsulated into this VPN service.
     - In wireless 3GPP applications, used to forward traffic that is
       mapped into the UMTS Interactive Traffic Class with Traffic
       Handling Priority 1 (THP=1)

   Traffic characteristics:
     - Variable size packets (50 to 1500 bytes in size)
     - Higher the rate, higher density of large packets
     - Variable packet emission time
     - Source capable of reducing its transmission rate based on
       detection of packet loss at the receiver

   Packet Marking:
     - Interactive gaming packets are marked with AF41
     - Video conferencing packets are marked with AF4x



Babiarz et al.            Expires April 2004                 [Page 20]


Internet Draft          DiffServ-Basic-Classes            October 2003

     - VPN service may be marked with AF4x depending on the service
       characteristics
     - Server to server data transfer with AF4x depending on the
       service characteristics
     - UMTS Interactive THP=1 packets are marked with AF4x

   Packet flows from video conferencing equipment may be marked at
   source by the video conferencing equipment or by the edge router
   using Two Rate Three Color Marked (trTCM) as specified in RFC 2698
   [18].

   Example of DSCP marking when performed by video conferencing
   equipment:
     - AF41 = H.323 video conferencing audio stream RTP/UDP
     - AF41 = H.323 video conferencing video control RTCP/TCP
     - AF41 = H.323 video conferencing video stream below specified
       rate "A"
     - AF42 = H.323 video conferencing video stream between specified
       rate "A" and "B"
     - AF43 = H.323 video conferencing video stream above specified
       rate "B"
     - Where rate "B" is greater in magnitude than rate "A"

   Conditioning Performed at DiffServ Network Edge:
     The Two Rate Three Color Marker (trTCM) should be used as specified
     in RFC 2698 [18].

     If packets are marked by the sources or previous DiffServ domain,
     then the trTCM should be configured to operate in Color-Aware mode.

     If the packets are not marked by the source or previous DiffServ
     domain, then the trTCM must be configured to operate in Color-Blind
     mode.

   The fundamental service offered to "Multimedia Conferencing" traffic
   is best effort service with controlled rate and delay. Some traffic
   in this service class may not respond dynamically to packet loss.
   For video conferencing service, typically a 1% packet loss detected
   at the receiver triggers encoding rate change, drop to next lower
   provisioned video encoding rate. As such, Active Queue Management
   [6] is used primarily to switch video encoding rate under
   congestion, change from high rate to lower rate i.e. 1472 kbps to
   768 kbps. The probability of loss of AF41 traffic may not exceed the
   probability of loss of AF42 traffic, which in turn may not exceed
   the probability of loss of AF43 traffic.









Babiarz et al.            Expires April 2004                 [Page 21]


Internet Draft          DiffServ-Basic-Classes            October 2003

4.2 Responsive Traffic Category

   Responsive traffic category can be further split into two service
   classes, Multimedia Streaming and Low Latency Data to provide
   differentiation based on the different behavior of source traffic
   being forwarded.




4.2.1 Multimedia Streaming Service Class


   The Multimedia Streaming service class is used for applications that
   require near-real-time packet forwarding of variable rate traffic
   sources which are not as delay sensitive as applications using the
   Multimedia Conferencing service class.  Such applications include
   broadcast TV, streaming audio and video, video (movies) on demand
   and surveillance video.  In general, the Multimedia Streaming
   service class assumes that the traffic is buffered at the
   source/destination and therefore, is less sensitive to delay and
   jitter.

   The Multimedia Streaming service class uses the Assured Forwarding
   (AF) PHB defined in RFC 2597 [11]. This service class is configured
   to provide a minimum bandwidth assurance for AF31, AF32, AF33 and
   CS4 marked packets to ensure that they get forwarded. The Multimedia
   Streaming service class should be configured to use Rate Queuing
   system such as defined in Section 1.2.1.2 of this document.

   Target application for Multimedia Streaming service class:
     - Video surveillance and security (unicast)
     - TV broadcast including HDTV (multicast)
     - Pay per view movies and events (pre scheduled)
     - Video on demand (unicast) with control (virtual DVD)
     - Streaming audio (unicast)
     - Streaming video (unicast)
     - Web casts
     - VPN service that supports different levels of flow assurance
     - In wireless 3GPP applications, used to forward traffic that is
       mapped into the UMTS Streaming Traffic Class

   Traffic Characteristics:
     - Variable size packets (50 to 4196 bytes in size)
     - Higher the rate, higher density of large packets
     - Variable packet emission rate
     - Some bursting at start of flow from some applications
     - At about 2% packet loss, video session is usually terminated

   Both the AF3x and CS4 DS codepoints are mapped into the Multimedia
   Streaming service classes and used the Assured Forwarding (AF) PHB
   however, Active Queue Management (AQM) mechanism is not applied in
   the router(s) to CS4 market packets.

Babiarz et al.            Expires April 2004                 [Page 22]


Internet Draft          DiffServ-Basic-Classes            October 2003


   Applications or end systems pre-mark their packets with DSCP values
   as shown in Table 3 below. If host is unable to pre-mark their
   packets, then marking is performed on the DiffServ edge router using
   MF classification. Due to the nature of the service, it is
   recommended that video surveillance and security flows are market
   with a different DSCP value so that traffic conditioning and
   policing policies can be different from other flows in the
   Multimedia Streaming service class.

    ------------------------------------------------------------------
   |    Applications                    |        Protocol        |DSCP|
   |------------------------------------+------------------------+----|
   |Video surveillance and security     |For RTP/UDP payload and |CS4 |
   | (unicast)                          |RTSP/TCP control streams|    |
   |------------------------------------+------------------------+----|
   |TV broadcast (multicast), pay per   |For RTP/UDP payloads and|    |
   |view movies and events (multicast)  |RTSP/TCP control streams|AF31|
   |Video on demand(unicast)with control|                        |    |
   |------------------------------------+------------------------+----|
   |                                    | For RTP/UDP streams    |AF33|
   |                                    |------------------------+----|
   | Video clips (unicast), premium WEB | For RTP/TCP streams    |AF32|
   |  casts, etc.                       |------------------------+----|
   |                                    | RTP/TCP or HTTP control|AF32|
   |------------------------------------+------------------------+----|
   |                                    | For RTP/UDP streams    |AF33|
   |                                    |------------------------+----|
   |  Audio streaming (unicast)         | For RTP/TCP streams    |AF32|
   |                                    |------------------------+----|
   |                                    |RTSP/TCP or HTTP control|AF31|
   |------------------------------------+------------------------+----|
   | VPN service that support different |                        |AF31|
   |  levels of assurance               |Implementation dependent|AF32|
   |                                    |                        |AF33|
   |------------------------------------+------------------------+----|
   |                                    |                        |AF31|
   | UMTS Streaming packets             | GPRS tunnel over IP    |AF32|
   |                                    |                        |AF33|
    ------------------------------------------------------------------
           Table 3: Example of DSCP marking for Multimedia Streaming

   Network Edge Conditioning:
     Packet flows from untrusted sources must be policed at the DiffServ
     network edge using single rate policers with a burst size control
     for AF31, AF32, AF33 and CS4 marked packets. Policing policy is
     based on the SLA for supported application(s). For the above
     defined applications, three single rate policers with burst size
     control should be provided; one for CS4 marked packets, another for
     AF31 marked packets and the third policer for AF32 and AF33 marked
     packets. Packet flows from trusted sources i.e. TV broadcast
     servers, etc. normally do not require policing.


Babiarz et al.            Expires April 2004                 [Page 23]


Internet Draft          DiffServ-Basic-Classes            October 2003


   The fundamental service offered to "Multimedia Streaming" traffic is
   best effort service with controlled rate and delay. This traffic
   does not respond dynamically to packet loss. Packets marked with
   AF31 and CS4 DSCP requires very high assurance of delivery. Packets
   marked with AF32 and AF33 can generally tolerated up to 1% and 2%
   packet loss respectfully. As such, Active Queue Management [6] is
   used primarily to reduce the number of flows at congestion points by
   dropping packets from less important flows first before any AF31 and
   CS4 marked packets are dropped. The service should be provisioned so
   that CS4 and AF31 marked packet flows have high assurance for
   bandwidth in the network. The probability of loss of CS4 traffic may
   not exceed the probability of AF31 and AF31 traffic may not exceed
   the probability of loss of AF32 traffic, which in turn may not
   exceed the probability of loss of AF33.


4.2.2 Low Latency Data Service Class

   The Low Latency Data service class is used for elastic and
   responsive typically client/server based applications.  Applications
   forwarded by this service class are those requiring 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 [1] short lived flows that require real-time
   packet forwarding of variable rate traffic sources.

   The Low Latency Data service class uses the Assured Forwarding (AF)
   PHB defined in RFC 2597 [11]. This service class is 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 Rate Queuing system such
   as defined in Section 1.2.1.2 of this document.

   Target applications for Low Latency Data service class:
     - Client / server applications
     - SNA terminal to host transactions (SNA over IP using DLSw)
     - Web based transactions (E-commerce)
     - Credit card transactions
     - Financial wire transfers
     - ERP applications (.e.g. SAP / BaaN)
     - Peer-to-peer signaling (SIP, H.323)
     - VPN service that supports CIR (Committed Information Rate) with
       up to two burst sizes
     - In wireless 3GPP applications, used to forward traffic that is
       mapped into the UMTS Interactive Traffic Class with Traffic
       Handling Priority 2 (THP=2)



Babiarz et al.            Expires April 2004                 [Page 24]


Internet Draft          DiffServ-Basic-Classes            October 2003

   Traffic Characteristics:
     - Variable size packets (50 to 1500 bytes in size)
     - Variable packet emission rate
     - With packet bursts of TCP window size
     - Source capable of reducing its transmission rate based on
       detection of packet loss at the receiver or through explicit
       congestion notification.

   Both the AF2x and CS3 DS codepoints are mapped into the Low Latency
   Data service classes and use the Assured Forwarding (AF) PHB
   however, Active Queue Management (AQM) mechanism is not applied in
   router(s) to CS3 market packets.

   DSCP marking:
     - Peer-to-peer inelastic SIP, H.323 signaling packer flows are
       marked with CS3
     - Elastic TCP flows are marked with AF2x
     - VPN service may be marked with AF2x or CS3 depending on the
       service characteristics
     - UMTS Interactive THP=2 packets are marked with AF2x

   Marking of the DSCP may be performed by a host or by an edge router.

   Conditioning Performed at the DiffServ Network Edge:
     Conditioning may be performed on per-flow or on aggregated-flows
     depending on the configuration and service offered. Metering and
     (re)marking of flows is required at DiffServ edge node and on
     DiffServ boundary node.  The Low Latency Data service class uses a
     Single Rate Three Color Marker (srTCM) conditioner for AF2x flows.

   Conditioning Requirements for AF2x marked packets:
     Conditioning of aggregated packet flows destined for the Low
     Latency Data service class must be performed at the DiffServ edge
     of the network. Furthermore, conditioning should be performed using
     Single Rate Three Color Marker (srTCM) as defined in RFC 2697 [17].

     If the packets are not pre-marked then the srTCM must be configured
     to operate in the Color-Blind mode.

     If the packets are pre-marked by the source or previous network
     (boundary node) then the srTCM should be configured to operate in
     the Color-Aware mode.

   Conditioning Requirements for CS3 marked Packets:
     DiffServ edge and boundary nodes must police CS3 marked packets so
     both rate and burst size can be enforced.

   The fundamental service offered to "Low Latency Data" traffic is
   best effort service with controlled rate and delay. The service
   should be engineered so that AF21 and CS3 marked packet flows have
   sufficed bandwidth in the network to provide high assurance of
   delivery. Since this traffic is marked with AF2x DSCP is elastic and
   responds dynamically to packet loss, Active Queue Management [6] is

Babiarz et al.            Expires April 2004                 [Page 25]


Internet Draft          DiffServ-Basic-Classes            October 2003

   used primarily to control TCP flow rates at congestion points by
   dropping packet from TCP flows where the burst length is high. The
   probability of loss of CS3 traffic may not exceed the probability of
   loss of AF21 and AF21 traffic may not exceed the probability of loss
   of AF22 traffic, which in turn may not exceed the probability of
   loss of AF23. Active queue management may also be implemented using
   Explicit Congestion Notification (ECN) [17] method as defined in RFC
   3168.


4.3 Timely Traffic Category

   Timely traffic category can be further split into two service
   classes, High Throughput Data and Standard to provide
   differentiation based on the different behavior of source traffic
   being forwarded.


4.3.1 High Throughput Data Service Class


   The High Throughput Data service class is configured to support
   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[1] or a
   transport with a consistent Congestion Avoidance Procedure[9][10]
   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 uses the Assured Forwarding
   (AF) PHB defined in RFC 2597 [11]. This service class is configured
   to provide a minimum bandwidth assurance for AF11, AF12, AF13 and
   CS2 marked packets to ensure that they are forwarded. The High
   Throughput Data service class should be configured to use Rate
   Queuing system such as defined in Section 1.2.1.2 of this document.

   Target applications for High Throughput Data service class:
     - Store and forward applications
     - File transfer applications
     - Email
     - Non-critical OAM&P (Operation and Management and Provisioning)
       using SNMP, XML, etc.
     - VPN service that supports CIR (Committed Information Rate) with
       up to two burst sizes
     - In wireless 3GPP applications, used to forward traffic that is
       mapped into the UMTS Interactive Traffic Class with Traffic
       Handling Priority 3 (THP=3)

   Traffic Characteristics:
     - Variable size packets (50 to 1500 bytes in size)
     - Variable packet emission rate

Babiarz et al.            Expires April 2004                 [Page 26]


Internet Draft          DiffServ-Basic-Classes            October 2003

     - With packet bursts of TCP window size
     - Source capable of reducing its transmission rate based on
       detection of packet loss at the receiver or through explicit
       congestion notification.

   Both the AF1x and CS2 DS codepoints are mapped into the High
   Throughput Data service classes and use the Assured Forwarding (AF)
   PHB however, Active Queue Management (AQM) mechanism is not applied
   in router(s) to CS2 market packets.

   DSCP marking:
     - Non-critical OAM&P (SNMP, XML, etc.) packets are marked with CS2
     - Elastic TCP flows are marked with AF1x
     - VPN service may be marked with AF1x or CS2 depending on the
       service characteristics
     - UMTS Interactive THP=3 packets are marked with AF1x

   Note: Since the performance requirements for non-critical OAM&P
   traffic can be met with the High Throughput Data service class and
   the amount of non-critical OAM&P traffic is normally very small, we
   recommend that non-critical OAM&P traffic be marked with CS2 DSCP
   and forwarded using the High Throughput Data service class. The
   marking of non-critical OAM&P traffic with CS2 DS codepoint is
   recommended so that different conditioning, policing and queue
   management policies can be used for non-critical OAM&P.

   Marking of the DSCP may be performed by a host or by an edge router.

   Conditioning Performed at the DiffServ Network Edge:
     Conditioning may be performed on per-flow or for aggregated flows
     depending on the configuration and the service offered. Metering
     and (re)marking of DSCP is required at the DiffServ edge node and
     on the DiffServ boundary node.  The High Throughput Data service
     class uses a Single Rate Three Color Marker (srTCM) conditioner for
     AF1x flows and a single rate policer with a burst size limit for
     CS2 flows.

   Conditioning Requirements for AF1x marked Packets:
     Conditioning of aggregated packet flows destined for the High
     Throughput Data service class must be performed at the DiffServ
     edge of the network. Furthermore, conditioning should be performed
     as defined in RFC 2697 [17].

     If the packets are not pre-marked, then the srTCM must be
     configured to operate in the Color-Blind mode.

     If the packets are pre-marked by the source or previous network
     (boundary node) the srTCM should be configured to operate in the
     Color-Aware mode.

   Conditioning Requirements for CS2 marked Packets:
     DiffServ edge and boundary nodes must police CS2 marked packets so
     both rate and burst size can be enforced.

Babiarz et al.            Expires April 2004                 [Page 27]


Internet Draft          DiffServ-Basic-Classes            October 2003


   The fundamental service offered to "High Throughput Data" traffic is
   best effort service with a specified minimum rate. It can be assumed
   that this class will consume any available bandwidth, and packets
   traversing congested links may experience higher queuing delays
   and/or packet loss.

   Typical configurations use Explicit Congestion Notification [14] as
   defined in RFC 3168 or random packet dropping to implement Active
   Queue Management [6] and may impose a minimum or maximum rate. The
   probability of loss of AF11 traffic may not exceed the probability
   of loss of AF12 traffic, which in turn may not exceed the
   probability of loss of AF13 traffic. Ingress traffic conditioning
   passes traffic in the class up to some specified threshold marked as
   AF11, additional traffic up to some secondary threshold marked as
   AF12, and potentially passes additional traffic marked as 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.

   Packets marked with CS2 DSCP (OAM&P packets) should not be put
   through Active Queue Management [6] function.


4.3.2 Standard Service Class

   The Standard service class is used for all 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 no bandwidth, delay, loss or jitter assurances.
   The Standard service class uses the Default Forwarding (DF) PHB
   defined in RFC 2474 [7] and should be configured to receive a small
   percentage of forwarding resources (at least 5%). This service class
   should be configured to use Rate Queuing system such as defined in
   Section 1.2.1.2 of this document.

   Target application for the Standard service class:
     - Any undifferentiated application/packet flow transported through
       the DiffServ enabled network
     - In wireless 3GPP applications, used to forward traffic that is
       mapped into the UMTS Background Traffic Class

   Traffic Characteristics:
     - Non deterministic, mixture of everything

   The DSCP marking is DF (Default Forwarding)

   Network Edge Conditioning:
     There is no requirement that conditioning of packet flows be
     performed for this service class.



Babiarz et al.            Expires April 2004                 [Page 28]


Internet Draft          DiffServ-Basic-Classes            October 2003

   The fundamental service offered to the Standard service class is
   best effort service with active queue management to limit over-all
   delay. Typical configurations use Explicit Congestion Notification
   [14] or random packet dropping to implement Active Queue Management
   [6], and may impose a minimum or maximum rate on the queue.


4.4 Non-Critical Traffic Category
   Non-critical traffic category currently has only one service class
   defined for differentiation from Standard traffic. When a need arise
   other service class could be defined in the future.

4.4.1 Low Priority Data Service Class


   The Low Priority Data service class serves applications which run
   over TCP [1] or a transport with a consistent congestion avoidance
   procedure [9][10], and which the user is willing to accept service
   without guarantees.  This service class is specified in [20].

   Target application for the Low Priority Data service class:
     - Any TCP based application/packet flow transported through the
     DiffServ enabled network that does not require any bandwidth
     assurances.

   Traffic Characteristics:
     - Non real-time and elastic.

   The DSCP marking is CS1 (Class Selector 1)

   Network Edge Conditioning:
     There is no requirement that conditioning of packet flows be
     performed for this service class.

   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 use Explicit Congestion Notification [14] or
   random loss to implement active queue management [6].


5. Mapping Applications to Service Classes

   Here we provide some examples for mapping different applications
   into the defined service classes.

   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. Therefore we have determined that the

Babiarz et al.            Expires April 2004                 [Page 29]


Internet Draft          DiffServ-Basic-Classes            October 2003

   different signaling protocols be mapped to service classes that best
   meet the objectives. The following mapping is recommended:
     - SIP and H.323 are forwarded using Low Latency Data service class
     - H.248 and MEGACO are forwarded using the Telephony service class
     - SIP-T signaling between call servers in carrier's network using
       Network Control service class.
     - RSVP signaling, depends on the application. If RSVP signaling is
       "on-path" as used in InServ or NSIS that it needs to be forward
       from the same queue (service class) as application data that it
       is controlling. If it is "off-path" not along the same path as
       applications data than, Low Latency Data service class should be
       used for RSVP signaling.

   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 would suggest the following guidelines for
   NTP be used:
     - When NTP is used for providing high accuracy timing within
       administrator's (carrier's) network, the Administration service
       class should be used and NTP packets be marked with CS7 DSCP.
     - When NTP is used for providing high accuracy timing to end
       users/clients than the Telephony service class should be used
       and NTP packets be marked with CS5 DSCP.
     - For applications that require "wall clock" timing accuracy, the
       Standard service class should be used and packets should be
       marked with DF DSCP.


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 the network to 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 which the network must
   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


Babiarz et al.            Expires April 2004                 [Page 30]


Internet Draft          DiffServ-Basic-Classes            October 2003

   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.



7. Acknowledgements

   The authors acknowledge a great many inputs, most notably from Bruce
   Davie, Dave Oran, Ralph Santitoro, Gary Kenward, Francois Audet,
   Brian E Carpenter, Morgan Littlewood and Al Morton. Kimberly King,
   Joe Zebarth and Alistair Munroe each did a thorough proof-reading,
   and the document is better for their contributions.


8. Normative References


   [1]  Postel, J., "TRANSMISSION CONTROL PROTOCOL", STD 7, RFC 793,
   September 1981.

   [2]  BRADEN, B., CLARK, D. and S. SHENKER, "INTEGRATED SERVICES IN
   THE INTERNET ARCHITECTURE: AN OVERVIEW", RFC 1633, June 1994.

   [3]  BRADNER, S., "KEY WORDS FOR USE IN RFCS TO INDICATE REQUIREMENT
   LEVELS", BCP 14, RFC 2119, March 1997.

   [4]  ZHANG, L., BERSON, S., HERZOG, S. and S. JAMIN, "RESOURCE
   RESERVATION PROTOCOL (RSVP) -- VERSION 1 FUNCTIONAL SPECIFICATION",
   RFC 2205, September 1997.

   [5]  BAKER, F., KRAWCZYK, J. and A. SASTRY, "RSVP MANAGEMENT
   INFORMATION BASE USING SMIV2", RFC 2206, September 1997.

   [6]  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.

   [7]  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.

   [8]  BLAKE, S., BLACK, D., CARLSON, M., DAVIES, E., WANG, Z. and W.
   WEISS, "AN ARCHITECTURE FOR DIFFERENTIATED SERVICES", RFC 2475,
   December 1998.

   [9]  ALLMAN, M., PAXSON, V. and W. STEVENS, "TCP CONGESTION
   CONTROL", RFC 2581, April 1999.

   [10] FLOYD, S. and T. HENDERSON, "THE NEWRENO MODIFICATION TO TCP'S
   FAST RECOVERY ALGORITHM", RFC 2582, April 1999.


Babiarz et al.            Expires April 2004                 [Page 31]


Internet Draft          DiffServ-Basic-Classes            October 2003

   [11] HEINANEN, J., BAKER, F., WEISS, W. and J. WROCLAWSKI, "ASSURED
   FORWARDING PHB GROUP", RFC 2597, June 1999.

   [12] HERZOG, S., "RSVP EXTENSIONS FOR POLICY CONTROL", RFC 2750,
   January 2000.

   [13] Bernet, Y., "FORMAT OF THE RSVP DCLASS OBJECT", RFC 2996,
   November 2000.

   [14] Ramakrishnan, K., Floyd, S. and D. Black, "THE ADDITION OF
   EXPLICIT CONGESTION NOTIFICATION (ECN) TO IP", RFC 3168, September
   2001.

   [15] Baker, F., Iturralde, C., Le Faucheur, F. and B. Davie,
   "AGGREGATION OF RSVP FOR IPV4 AND IPV6 RESERVATIONS", RFC 3175,
   September 2001.

   [16] Herzog, S., "SIGNALED PREEMPTION PRIORITY POLICY ELEMENT", RFC
   3181, October 2001.

   [17] Heinanen, J. and Guerin, R. "A SINGLE RATE THREE COLOR MARKER",
   RFC 2697, September 1999.

   [18] Heinanen, J. and Guerin, R. "A TWO RATE THREE COLOR MARKER",
   RFC 2698, September 1999.

   [19] Davie, B., Charny, A., Bennet, J., 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.

   [20] "QBone Scavenger Service (QBSS) Definition", Internet2
   Technical Report Proposed Service Definition, March 2001.



9. Informative References

   [21] DURHAM, D., BOYLE, J., COHEN, R., HERZOG, S., RAJAN, R. and A.
   SASTRY, "THE COPS (COMMON OPEN POLICY SERVICE) PROTOCOL", RFC 2748,
   January 2000.

   [22] Bernet, Y. and R. Pabbati, "APPLICATION AND SUB APPLICATION
   IDENTITY POLICY ELEMENT FOR USE WITH RSVP", RFC 2872, June 2000.
   [23] Bonaventure, O. and S. De Cnodder, "A RATE ADAPTIVE SHAPER FOR
   DIFFERENTIATED SERVICES", RFC 2963, October 2000.

   [24] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K.,
   Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith, "COPS USAGE
   FOR POLICY PROVISIONING (COPS-PR)", RFC 3084, March 2001.





Babiarz et al.            Expires April 2004                 [Page 32]


Internet Draft          DiffServ-Basic-Classes            October 2003

   [25] Floyd, S. and V. Jacobson, "Random Early Detection Gateways for
   Congestion Avoidance", IEEE/ACM Transactions on Networking , August
   1993.

   [26] Zhang, L., "Virtual Clock: A New Traffic control Algorithm for
   Packet Switching Networks", ACM SIGCOMM 1990, September 1990.

   [27] Keshav, S., "On the Efficient Implementation of Fair Queueing",
   Internetworking: Research and Experiences Vol 2, September 1991.

   [28] Katevenis, M., Sidiropoulos, S. and C. Courcoubetis, "Weighted
   Round-Robin Cell Multiplexing in a General Purpose ATM Switch Chip",
   IEEE JSAC Vol. 9, No. 8, October 1991.

   [29] "International Emergency Preparedness Scheme", ITU E.106, March
   2000.

   [30] "Service Description for an International Emergency Multimedia
   Service (Draft)", ITU-T F.706, August 2001.



10. Author's Address

   Jozef Babiarz
   Nortel Networks
   3500 Carling Avenue
   Ottawa, Ont. Canada
   K2H 8E9
   Phone:       +1-613-763-6098
   Fax:         +1-613-768-2231
   EMail:       babiarz@nortelnetworks.com


   Fred Baker
   Cisco Systems
   1121 Via Del Rey
   Santa Barbara, CA 93117  USA
   Phone:       +1-408-526-4257
   Fax:         +1-413-473-2403
   EMail:       fred@cisco.com


   Kwok Ho Chan
   Nortel Networks
   600 Technology Park Drive
   Billerica, MA 01821  USA
   Phone:       +1-978-288-8175
   Fax:         +1-978-288-4690
   EMail:       khchan@nortelnetworks.com




Babiarz et al.            Expires April 2004                 [Page 33]


Internet Draft          DiffServ-Basic-Classes            October 2003

11. Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.























Babiarz et al.            Expires April 2004                 [Page 34]


Html markup produced by rfcmarkup 1.125, available from https://tools.ietf.org/tools/rfcmarkup/