[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 RFC 3290

   Differentiated Services                                  Y. Bernet
   Internet Draft                                           Microsoft
   Expires December 1999                                     A. Smith
   draft-ietf-diffserv-model-00.txt                  Extreme Networks
                                                             S. Blake
                                                     Ericsson Datacom
                                                            June 1999



                  A Conceptual Model for Diffserv Routers



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.

   Distribution of this memo is unlimited.

   Copyright Notice

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

Abstract

   This draft proposes a conceptual model for use in the management of
   Differentiated Services (diffserv) routers. We describe the
   fundamental packet classification principles that allow traffic
   streams to be differentiated. We describe the fundamental traffic
   conditioning elements that comprise the traffic conditioning
   functionality of diffserv routers. We describe the fundamental queue
   elements that comprise the Per-Hop Behaviour (PHB) functionality of
   diffserv routers. We propose a formal model for these. We also
   describe parameters and variables that may be used for monitoring
   the operation of the elements described above. There is no attempt
   made to define the packet forwarding behaviours of diffserv routers
   - these are well described elsewhere in the literature.

Bernet, Smith, Blake    expires December, 1999                       1


draft-ietf-diffserv-model-00.txt                             June, 1999


   This draft is preliminary and is known to be inconsistent in some
   respects with [DSMIB]. It is intended to correct this prior to the
   next version, as well as to verify full consistency with the
   published diffserv specifications [DSFIELD], [DSARCH], [AF-PHB],
   [EF-PHB].

1. Introduction

   Differentiated Services (diffserv) [DSARCH, DSFWK] is a set of
   technologies by which network service providers can offer differing
   levels of network quality-of-service (QoS) to different customers
   and their traffic streams. The premise of diffserv networks is that
   routers within the networks handle packets in different traffic
   streams by applying different per-hop behaviours (PHBs) to the
   packet forwarding. The PHB to be applied is indicated by a diffserv
   code-point (DSCP) in the IP header of each packet [DSFIELD]. Note
   that this document uses the terminology of [DSFWK].

   The advantage of such a scheme is that many traffic streams can be
   aggregated to one of a small number of behaviour aggregates (BA)
   which are each forwarded using the same PHB at the router, thereby
   simplifying the processing and associated storage. In addition,
   there is no signaling, other than what is carried in the DSCP of
   each packet, and no other related processing that is required in the
   diffserv network since QoS is invoked on a packet-by-packet basis.

   Although diffserv itself does not define the services that a
   diffserv network can provide, its successful deployment depends on
   the ability to use the technology to provide services. These
   services are reflected to customers at the edges of the diffserv
   network in the form of a Service Level Specification (SLS) [DSFWK].
   The ability to provide these services depends on the availability of
   cohesive management tools that can be used to provision and monitor
   a set of diffserv routers in a coordinated manner. To facilitate the
   development of such management tools it is helpful to define a
   conceptual model of a diffserv router that abstracts implementation
   details of diffserv routers from the management tools used to manage
   them. The purpose of this draft is to define this conceptual model.

   The basic forwarding functionality of a diffserv router is defined
   by other specifications e.g. [DSARCH], [DSFIELD], [AF-PHB], [EF-
   PHB].

   This document is not intended in any way to constrain or to dictate
   implementations of diffserv routers. We expect that router vendors
   will demonstrate a great deal of variability in their
   implementations. To the extent that vendors are able to model their
   implementations using the abstractions described in this draft,
   management tools will more readily be able to manage networks
   incorporating diffserv routers of various implementations.

2. Organization of this Document

Bernet, Smith, Blake    expires December, 1999                       2


draft-ietf-diffserv-model-00.txt                             June, 1999


   In Section 3 we start by describing the basic high-level functional
   blocks of a diffserv router and then providing a block diagram and
   describe the various components. We then focus on the diffserv-
   specific components of the router and describe a hierarchical
   management model for these.

   In Section 4 we describe classification elements and in section 5,
   we discuss the basic traffic conditioning elements.

   In Section 6, we show how the basic classification and traffic
   conditioning elements can be combined to build modules called
   Traffic Conditioning Blocks (TCBs).

   In Section 7, we discuss the basic queuing components.

   In Section 8, we discuss those parameters that it must be possible
   to monitor for the purposes of managing a diffserv router.

3. Elements of a Diffserv Router

   In this section we introduce a block diagram of a diffserv router
   and describe the various components illustrated. Note that the
   functions of a diffserv core router are likely to be a much
   simplified set of these components: the model we present here is
   intended to cover the case of a diffserv edge router as well as the
   core.

3.1 Conceptual Model

   The conceptual model we define includes abstract definitions of the
   following:

   1. The basic traffic classification components.
   2. The basic traffic conditioning components.
   3. Certain combinations of traffic conditioning components.
   4. Queuing components.

    The components and combinations of components described in this
    document form building blocks that need to be manageable by
    diffserv management tools. One of the goals of this document is to
    show how a model of a diffserv device can be built up out of these
    component blocks. This model is in the form of a connected acyclic
    directional graph that describes the traffic conditioning behaviour
    that any particular data packet will experience when submitted to
    the diffserv router.

    It is anticipated that these building blocks may also be used as
    the basis for a diffserv MIB or other such specific device
    configuration mechanisms.




Bernet, Smith, Blake    expires December, 1999                       3


draft-ietf-diffserv-model-00.txt                             June, 1999

3.2 Block Diagram

   The following diagram illustrates the major functional blocks of a
   diffserv router:

            +--------------+
            |  diffserv    |
      Mgmt  | configuration|
    <------>| & monitoring |----------------
    SNMP,|  |  interface   |               |
    COPS |  +--------------+               |
    etc. |       |                         |
         |       |                         |
         |       v                         v
         |  +----------+   +-------+   +---------+   +-------+
    data |  |ingress   |   |routing|   |egress   |   |queuing|
    ------->|-classif. |-->|       |-->|-classif.|-->| stuff |-->
         |  |-TCB      |   +-------+   |-TCB     |   +-------+
         |  +----------+               +---------+
         |       ^                         ^
         |       |                         |
         |  +----------+                   |
         -->|          |                   |
    ------->|  RSVP    |--------------------
      RSVP  |(optional)|
      cntl  +----------+
      msgs

   In this diagram, a Traffic Conditioning Block (TCB) represents a
   combination of metering, marking, shaping, dropping elements that
   are discussed in more detail below.

3.2.1 Interfaces, Classification, Traffic Conditioning, Queuing and the
Routing Core

   An ingress interface, routing component and egress interface are
   illustrated at the center of the diagram. In actual router
   implementations, there may be an arbitrary number of inbound and
   outbound interfaces interconnected by the routing core. The
   components of interest on these interfaces are the traffic
   classifiers, the traffic conditioning components (TC) and the
   queuing components that support the Per-Hop Behaviour (PHB)
   [DSARCH]. These are the fundamental components comprising a diffserv
   router and will be the focal point of our conceptual model.

3.2.2 Diffserv Configuration and Monitoring Interface

   Diffserv operating parameters are monitored and provisioned through
   this interface. Monitored parameters include statistics regarding
   traffic carried at various diffserv service levels. These statistics
   are important for accounting purposes and for tracking compliance to
   service level agreements (SLAs [DSARCH]) negotiated with customers.



Bernet, Smith, Blake    expires December, 1999                       4


draft-ietf-diffserv-model-00.txt                             June, 1999

   Provisioned parameters are primarily classification rules, PHB and
   TC configuration parameters. The network administrator interacts
   with the diffserv configuration and monitoring interface via one or
   more management protocols, such as SNMP or COPS [COPS] or through
   other router configuration tools such as serial terminal or telnet
   consoles.

3.2.3 Optional RSVP Module

   Diffserv routers may snoop or participate in either per-microflow or
   per-flow-aggregate signaling of QoS requirements [E2E]. The example
   discussed here uses the RSVP protocol. Snooping of RSVP messages may
   be used, for example, to learn how to classify traffic without
   actually participating as a RSVP protocol peer. Diffserv routers may
   reject or admit RSVP reservation requests to provide a means of
   admission control to diffserv-based services or they may use these
   requests to trigger provisioning changes for a flow-aggregation in
   the diffserv network. A flow-aggregation in this context might be
   equivalent to a diffserv BA or it may be more fine-grained, relying
   on a MF classifier. Note that the conceptual model of such a router
   starts to look the same as a Integrated Services (intserv) router in
   its component makeup [E2E].

   Note that a RSVP component of a diffserv router, if present, might
   be active only in the control plane and not in the data plane. In
   this scenario, RSVP is used strictly as a signaling protocol. The
   data plane of such a diffserv router can still act purely on
   diffserv DSCPs and PHBs in handling data traffic.

3.3 Hierarchical Model of Diffserv Components

   We focus on the diffserv specific functional components of the
   router, the traffic conditioning and queuing functionality. The
   example below is based on the larger block diagram shown above:

                  Interface A                        Interface B
                  +------------+     +-------+     +------------+
          ------->|  ingress   |---->|       |---->|  egress    |--->
                  |(class.,TC) |     |       |     |(queuing,TC)|
                  +------------+     |routing|     +------------+
                                     |       |
                  +------------+     |       |     +------------+
          <-------|  egress    |<----|       |<----|  ingress   |<---
                  |(queuing,TC)|     +-------+     |(class.,TC) |
                  +------------+                   +------------+

                Figure 1 - Traffic Conditioning and Queuing

   This diagram illustrates two diffserv router interfaces, each having
   an ingress and an egress component. It shows classification and TC
   components on each interface's ingress and it shows both TC and PHB
   components on each interface's egress. From a management
   perspective, the following hierarchy exists:

Bernet, Smith, Blake    expires December, 1999                       5


draft-ietf-diffserv-model-00.txt                             June, 1999


   At the top level, the router manager manages interfaces. Each
   interface consists of an ingress component and an egress component.
   An ingress component contains TC components. An egress component
   contains PHB components and TC components. (There may be special
   cases in which a router implements PHB components on an ingress
   interface. This model is readily extensible to reflect such an
   implementation. However, we have chosen not to do so in this case.)

   The TC components on each interface are described by a traffic
   conditioning table (TCT) corresponding to the interface. The TCT
   describes traffic classification and conditioning elements and how
   they are combined to provide the interface's traffic conditioning
   functionality. Certain traffic conditioning elements may be grouped
   into traffic conditioning blocks (TCBs).

   PHB components contain queues and the enqueuing and dequeuing
   algorithms that serve them. Queues are each independently
   parameterized. There may also be parameters defining relationships
   between PHBs.

4. Classification Elements

   Classification is a necessary function for any device that treats
   certain traffic differently from other traffic. The very nature of a
   diffserv router is that it treats traffic differentially. Therefore,
   classification is the most basic function required from a
   differentiated service router.

   Classification is performed by a classifier. Classifiers take a
   single traffic stream as input and generate logically separate
   traffic streams as output. Packets from the input stream are sorted
   into various output streams depending on the contents of the packet
   and possibly on other sources of information e.g. input sub-channel
   number. The various types of classifiers are described in the
   following sections.

4.1 Behaviour Aggregate (BA) Classifier

   The simplest diffserv classifier is a behaviour aggregate (BA)
   classifier. A BA classifier uses only the diffserv codepoint (DSCP)
   in a packet's IP header to determine the logical output stream to
   which the packet should be directed.

4.2 Multi-Field (MF) Classifier

   Another type of classifier is a multi-field (MF) classifier. This
   classifies packets based on one or more fields in the packet header
   other than the DSCP. A common type of MF classifier is a 5-tuple
   classifier that classifies based on the five IP header fields of
   source/destination address, source/destination port and IP protocol
   number. MF classifiers may classify based on other fields such as


Bernet, Smith, Blake    expires December, 1999                       6


draft-ietf-diffserv-model-00.txt                             June, 1999

   MAC addresses, VLANs, link-layer traffic class or other higher layer
   protocol addresses.

4.3 Other Classifier Types

   Classification may be performed based on implicit information
   associated with a packet (e.g. the incoming channel number on a
   channelized interface) or on information derived from a different
   classification operation (e.g. the outgoing interface determined by
   the route lookup operation). We do not discuss these further here.

4.4 Filters

   Classifiers are parameterized by filters and output streams. For
   example, the following classifier separates traffic into one of
   three output streams based on two filters:

          Filter Matched        Output Stream
          --------------       ---------------
               1                      A
               2                      B
            no match                  C

   Where filters 01 and 02 are defined to be the following BA filters:

          Filter        DSCP
          ------       ------
           1           101010
           2           111111

   A filter consists of a set of conditions on the component values of
   a classification key. In the BA classifier example above, the
   classification key consists of one packet header field, the DSCP,
   and both Filter1 and Filter2 specify exact-match conditions on the
   value of the DSCP.  The third filter is a wildcard default filter
   which matches every packet, but which is only selected in the event
   that no other more specific filter matches.

   In general there are a whole set of possible component conditions
   including exact, prefix, range, wildcard and masked matches. Note
   that ranges can be represented (maybe less efficiently) as a set of
   prefix matches and that prefix matches are just a special case of
   masked matches.

   In the case of a MF classifier, the classification key consists of a
   number of packet header fields.  The filter may specify a different
   condition for each key component, as illustrated in the example
   below for a TCP/IPv4 classifier:

    Filter  IP Src Addr    IP Dest Addr    TCP SrcPort  TCP DestPort
    ------  -------------  -------------   -----------   ------------
    Filter1 172.31.8.1/32  172.31.3.X/24       X             5003


Bernet, Smith, Blake    expires December, 1999                       7


draft-ietf-diffserv-model-00.txt                             June, 1999

   In this example, the fourth octet of the destination IPv4 address
   and the source TCP port are 'don't cares'.

4.5 Diagram of a Classifier

   We use the following diagram to illustrate a classifier, where the
   outputs are to be plumbed in to succeeding TC elements:

            unclassified            classified
              traffic                traffic
                     -----------
                     |         |--> match Filter1 --> output A
               ----->|classifer|--> match Filter2 --> output B
                     |         |--> no match --> output C
                     -----------

                     Figure 2 - An Example Classifier

   Note that an input interface number can also be considered as an
   input to the classifier if the classifier is modeled as accepting
   packets from multiple input ports - this optimisation may be
   important for scalability in the management plane.

4.6 Formal Representation of Classifiers

4.6.1 IPv4 5-tuple Classifier

   The following formal definition can be used to represent a
   classifier using masked match conditions:

          <Editorial Note: are masked matches sufficient? Do we need
          ranges here? Can we narrow it down even more to prefix match
          conditions for some/all fields?>

   Classifier0:
   Filter1:     output A
   Filter2:     output B
   No Match:    output C

   Filter1:                          Filter2:
   Type:              IPv4 5-tuple   Type:             IPv4 5-tuple
   Ipv4SrcAddrValue:  172.31.8.0     Ipv4SrcAddrValue: 172.31.9.0
   Ipv4DestAddrValue: 0              Ipv4DestAddrValue:0
   Ipv4SrcPortValue:  0              Ipv4SrcPortValue: 0
   Ipv4DestPortValue: 5003           Ipv4DestPortValue:5003
   Ipv4ProtocolValue: 0              Ipv4ProtocolValue:0
   Ipv4SrcAddrMask:   255.255.255.0  Ipv4SrcAddrMask:  255.255.255.0
   Ipv4DestAddrMask:  0.0.0.0        Ipv4DestAddrMask: 0.0.0.0
   Ipv4SrcPortMask:   0              Ipv4SrcPortMask:  0
   Ipv4DestPortMask:  0xFFFF         Ipv4DestPortMask: 0xFFFF
   Ipv4ProtocolMask:  0              Ipv4ProtocolMask: 0

4.6.2 IPv6 5-tuple Classifier

Bernet, Smith, Blake    expires December, 1999                       8


draft-ietf-diffserv-model-00.txt                             June, 1999


   The following formal definition can be used to represent a IPv6
   multi-field classifier using masked match conditions:

   Classifier1:
   Filter3:     output A
   No Match:    output B

   Filter3:
   Type:                 IPv6 5-tuple
   Ipv6SrcAddrValue:     0:0:0:0:0:FFFF:32.12.65.0
   Ipv6SrcAddrMask:      FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:255.255.255.0
   Ipv6DestAddrValue:    1080:0:0:0:0:0:0:0
   Ipv6DestAddrMask:     FFFF:FFFF:FFFF:FFFF:0:0:0:0
   Ipv6SrcPortValue:     0
   Ipv6SrcPortMask:      0
   Ipv6DestPortValue:    5003
   Ipv6DestPortMask:     0xFFFF
   Ipv6NextHeaderValue:  6
   Ipv6NextHeaderMask:   0xFF

4.6.3 Behaviour Aggregate Classifier

   A BA classifier is parameterised by a set of 6-bit DSCP {value,
   mask} pairs:

   Classifier1:
   Filter3:     output A
   Filter4:     output B
   No Match:    output C

   Filter3:             Filter4:
   Type:        BA      Type:   BA
   Value:       111000  Value:  110000
   Mask:        111111  Mask:   111111

   <note: can IPv4 and IPv6 BA classifiers be modeled the same as each
   other?>

4.6.4 IEEE802 MAC Address Classifiers

   A MacAddress classifier is parameterised by a 6-byte {value, mask}
   pair for either source or destination MAC address.l for example, the
   following classifier sends packets matching either DA 01-02-03-04-
   05-06 or SA 00-E0-2B-XX-XX-XX to output A:

   Classifier2:
   Filter5:     output A
   Filter6:     output A
   No Match:    output B

   Filter5:
   Type:        DestMacAddress

Bernet, Smith, Blake    expires December, 1999                       9


draft-ietf-diffserv-model-00.txt                             June, 1999

   Value:       01-02-03-04-05-06 (hex)
   Mask:        FF-FF-FF-FF-FF-FF (hex)

   Filter6:
   Type:        SrcMacAddress
   DestValue:   00-E0-2B-00-00-00 (hex)
   DestMask:    FF-FF-FF-00-00-00 (hex)

4.6.5 Free-form Classifier

   A FreeForm classifier is made up of a set of user definable
   arbitrary filters each made up of {bit-field size, offset (from head
   of packet), mask}:

   Classifier3:
   Filter6:     output A
   Filter7:     output B
   No Match:    output C

   Filter6:
   Type:        FreeForm
   SizeBits:    3 bits
   Offset:      16 bytes
   Value:       100 (binary)
   Mask:        101 (binary)

   Filter7:
   Type:        FreeForm
   SizeBits:    12 bits
   Offset:      16 bytes
   Value:       100100000000 (binary)
   Mask:        111111111111 (binary)

4.6.6 Other Standard Classifiers

   e.g. IEEE802.1p, IEEE802.1Q VLAN-ID

   Classifier4:
   Filter8:     output A
   Filter9:     output B
   No Match:    output C

   Filter8:
   Type:        IeeePriority
   Value:       100 (binary)
   Mask:        101 (binary)

   Filter9:
   Type:        IeeeVlan
   Value:       100100000000 (binary)
   Mask:        111111111111 (binary)

4.6.7 Vendor-Specific Classifier

Bernet, Smith, Blake    expires December, 1999                      10


draft-ietf-diffserv-model-00.txt                             June, 1999


   Other vendor specific filter formats.

4.7 Combinations of Filters

   Filters may be logically combined. For example, consider the
   following DestMacAddress filter:

   Filter3:
   Type:        DestMacAddress
   Value:       01-02-03-04-05-06
   Mask:        FF-FF-FF-FF-FF-FF

   Classifier0 could then be declared as:

   Classifier0:
   Filter1 and Filter3:         output A
   Filter2 and Filter3:         output B
   No Match:                    output C

4.7.1 Conflicting Filters

   Note that it is easy to define sets of conflicting filters in a
   classifier. For example:

   Filter1:             Filter2:
   Type:        BA      Type:   BA
   Value:       111000  Value:  000111 (binary)
   Mask:        111000  Mask:   000111 (binary)

   A packet containing the DSCP 111111 cannot be uniquely classified by
   this set of filters and so a precedence must be established between
   Filter1 and Filter2 in order to break the tie. This precedence must
   be established either (a) by a manager which knows that the router
   can accomplish this particular ordering e.g. by means of reported
   capabilities or (b) by the router along with a mechanism to report
   to a manager which precedence is being used. These ordering
   mechanisms must be supported by the management protocol although
   further discussion of this is outside the scope of this document.

5. Traffic-Conditioning Elements

   Traffic-conditioning is a essential function of a diff-serv router,
   defined in [DSARCH]. This section defines the elements that can be
   combined to provide the traffic-conditioning functionality
   described. These include meters and various action elements.

5.1 Meters

   Metering is the function of monitoring the arrival times of packets
   on a traffic stream and determining the level of conformance of each
   packet to a profile. Diffserv network providers may offer services
   to customers based on a temporal profile within which the customer

Bernet, Smith, Blake    expires December, 1999                      11


draft-ietf-diffserv-model-00.txt                             June, 1999

   submits traffic for the service.  In this event, a meter might be
   used to trigger real-time effects (e.g. marking) downstream; it
   might also just be used for out-of-band management functions like
   statistics monitoring and billing applications.

   Meters are parameterized by a temporal profile and by conformance
   levels.

5.1.1 Types of Meters

5.1.1.1 Average Rate Meter

   An example of a very simple meter is an average rate meter. This
   type of meter measures the average rate at which packets are
   submitted to it over a specified averaging time.

   An average rate profile may take the following form:

   Average Rate: 10 packets per second
   Averaging Interval: 1 second

   A meter measuring against this profile would continually maintain a
   count that indicates the total number of packets arriving between
   time T (now) and time T-1 second. So long as an arriving packet does
   not push the count over 10, the packet would be deemed conforming.
   Any packet that pushes the count over 10, would be deemed non-
   conforming. Thus, this meter deems packets to correspond to one of
   two conformance levels - conforming or non-conforming.

5.1.1.2 Exponential Weighted Moving Average Meters

   The EWMA form of meter is easy to implement in silicon and can be
   parameterised as follows:

     avg(n+1) = (1-Gain) * avg(n) +  Gain * actual(n+1)
     t(n+1) = t(n) + Delta

  For a packet arriving at time t(m):

     if (avg(m) > AverageRate)
        non-conforming
     else
        conforming

   Gain controls the time constant (e.g. frequency response) of what is
   essentially a simple IIR low-pass filter. actual(n) and avg(n)
   measure the number of incoming bytes in a small fixed sampling
   interval, Delta. Any packet that arrives and pushes the average rate
   over a predefined rate AverageRate is deemed non-conforming.

5.1.1.3 Token Bucket Meters



Bernet, Smith, Blake    expires December, 1999                      12


draft-ietf-diffserv-model-00.txt                             June, 1999

   A more sophisticated meter might measure conformance to a token
   bucket (TB) profile. A TB profile generally has three parameters, an
   average rate, a peak rate and a burst size. TB meters compare the
   arrival rate of packets to the average rate specified by the TB
   profile. Logically, byte tokens accumulate in a bucket at the
   average rate, up to a maximum credit which is the burst size.
   Packets of length L bytes are considered conforming if L tokens are
   available in the bucket at the time of packet arrival. Packets are
   allowed to exceed the average rate in bursts up to the burst size,
   so long as they do not exceed the peak rate, at which point the
   bucket will be drained. Packets which arrive to find a bucket with
   insufficient tokens in it are deemed non-conforming.

   More complicated token bucket models might define two burst sizes
   and three conformance levels. Packets found to exceed the larger
   burst size are deemed non-conforming. Packets found to exceed the
   smaller burst size are deemed partially conforming. Packets
   exceeding neither are deemed conforming. Token bucket meters
   designed for diff-serv networks are described in more detail in
   [SRTCM], [TRTCM] and [GTC]: in some of these references, three
   levels of conformance are discussed in terms of colors, with green
   representing conforming, yellow representing partially conforming
   and red representing non-conforming.

5.1.2 Diagram of a Meter

   We use the following diagram to illustrate a meter with 3 levels of
   conformance:

                unmetered               metered
                 traffic                traffic

                         -----------
                         |         |--------> conformanceA
               --------->|  meter  |--------> conformanceB
                         |         |--------> conformanceC
                         -----------

                        Figure 3 - An Example Meter

   In some diffserv examples, three levels of conformance are discussed
   in terms of colors, with green representing conforming, yellow
   representing partially conforming and red representing non-
   conforming. Other example meters use a binary notion of conformance;
   in the general case there are 'N' levels of conformance.

5.1.3 Formal Representations of Meters

5.1.3.1 Simple Token Bucket Meter

   The following formal definition can be used to represent this meter:

   Meter1:

Bernet, Smith, Blake    expires December, 1999                      13


draft-ietf-diffserv-model-00.txt                             June, 1999

   Type:                SimpleTokenBucket
   Profile1:            output A
   NonConforming:       output B

   Profile1:
   Type:                SimpleTokenBucket
   AverageRate:         100 Kbps
   PeakRate:            150 Kbps
   BurstSize            100 Kb

5.1.3.2 EWMA Meter

   Meter2:
   Type:                ExpWeightedMovingAvg
   Profile2:            output A
   NonConforming:       output B

   Profile2:
   Type:                ExpWeightedMovingAvg
   Gain:                1/16
   Delta:               10us
   AverageRate:         200 Kbps

5.1.3.3 Two-level Token Bucket Meter

   Meter3:
   Type:                TwoLevelTokenBucket
   Profile3:            output A
   Profile4:            output B
   NonConforming:       output C

   Profile3:
   Type:                SimpleTokenBucket
   AverageRate:         100 Kbps
   PeakRate:            150 Kbps
   BurstSize            50 Kb

   Profile4:
   Type:                SimpleTokenBucket
   AverageRate:         120 Kbps
   PeakRate:            150 Kbps
   BurstSize            100 Kb

5.1.3.4 Average Rate Meter

   Meter4:
   Type:                AverageRate
   Profile5:            output A
   NonConforming:       output B

   Profile5:
   Type:                AverageRate
   AverageRate:         120 Kbps

Bernet, Smith, Blake    expires December, 1999                      14


draft-ietf-diffserv-model-00.txt                             June, 1999

   Delta:               100us

5.1.3.5 Other Vendor-specific Meters

   Other vendor specific meters are also possible.

5.2 Action Elements

   Classifiers and meters are generally used to determine the
   appropriate action to apply to a packet. The set of possible non-
   exclusive actions include:

   1) Marking
   2) Shaping
   3) Dropping
   4) Monitoring

   The corresponding action elements are described in the following
   paragraphs. Each of these actions has a default treatment which is
   to simply pass the packet on to a PHB queue.

   Policing is a general term for the action of preventing a traffic
   stream from seizing more than its share of resources from a diffserv
   network. Each of the three action elements described may be used to
   police traffic. Markers do so by re-marking submitted packets to a
   DSCP that is entitled to less network resources. Shapers and
   droppers do so by limiting the rate at which a particular traffic
   stream is submitted to the network.

5.2.1 Markers

   Markers set the DSCP in a packet header. Markers may act on unmarked
   packets (submitted with DSCP of zero) or may re-mark previously
   marked packets. In particular, the model supports the application of
   marking based on a preceding classifier match. The DSCP set in a
   packet will determine its subsequent treatment both by any following
   classifier elements within the same node or by other nodes
   downstream in the diffserv network.

   Markers are parameterized by a single parameter - the six-bit DSCP
   to be marked in packet headers.

5.2.1.1 Formal Representation of a Marker

   The following formal definition can be used to represent a marker:

   ActionElement1:
   Type:                Marker
   Mark:                010010
5.2.2 Shapers

   Shapers are used to shape traffic to a certain temporal profile. For
   example, a shaper can be used to smooth traffic arriving in bursts.

Bernet, Smith, Blake    expires December, 1999                      15


draft-ietf-diffserv-model-00.txt                             June, 1999

   Shapers operate by delaying packets that would be deemed non-
   conforming to the shaper's profile. The packet is delayed until such
   time that it becomes conforming. Consider the average rate profile
   described previously. In the case that a burst of 11 packets was
   submitted simultaneously to a meter using the average rate profile,
   the 11th packet would be deemed non-conforming. In order to be
   deemed conforming, the packet would have to be delayed by one
   second. Thus, a shaper parameterized by the average rate profile
   (see section 5.1.1.1) would delay the 11th packet for one second.
   Shapers are parameterized by a single temporal profile e.g. a token
   bucket.

   Implicit in the definition of a shaper is a notion of a queue and a
   queue depth: in order to delay a packet, a shaper must have
   somewhere to store the packet and that storage area often has finite
   size. The queue is modeled here as a simple FIFO with a finite
   depth. Packets are dropped if the depth is exceeded - this is
   considered to be an error condition.

5.2.2.1 Uses of Shapers

   Shapers are often used to pre-condition traffic such that packets
   are not deemed non-conforming by subsequent meters, e.g. in
   downstream diffserv nodes. Shapers may also be used to isolate
   certain traffic streams from the effects of other traffic streams of
   the same BA. For example, consider the case of two traffic streams
   that are submitted to a diffserv network for a particular diffserv
   service level. The agreement between the customer and the diffserv
   network provider limits the rate of traffic that can be submitted at
   a certain service level. In this case, one of the two traffic
   streams may attempt to seize more than its fair share of the
   available capacity for the service level. By doing so, it
   compromises the other traffic stream. A shaper that acts
   independently on the two streams can be used to limit the effect of
   the rogue stream. Note also that a BA might be metered against one
   profile whilst being shaped to a different profile further
   downstream in the same device.

5.2.2.2 Formal Representation of a Shaper

   The following formal definition can be used to represent a shaper:

   ActionElement2:
   Type:        Shaper
   Profile:     Profile1
   QueueDepth:  size in bytes and/or packets

   Profile definitions are identical in format to those described under
   the formal definition of a meter.

   <note: do we need to discuss dropping algorithms for shapers here?>

5.2.3 Droppers

Bernet, Smith, Blake    expires December, 1999                      16


draft-ietf-diffserv-model-00.txt                             June, 1999


   Droppers simply discard packets. There are no parameters for
   droppers.

5.2.3.1 Formal Representation of a Dropper

   The following formal definition can be used to represent a dropper:

   ActionElement03:
   Type:        Dropper

5.2.4 Monitoring

   One passive form of an action to be taken is simply to account for
   the fact that a data packet was processed. This might be used later
   on in presenting statistics for customer usage-based  billing.
   Further discussion of instrumentation for monitoring is provided in
   section 0 although the topic of accounting is not dealt with in
   detail here.

6. Traffic Conditioning Blocks (TCBs)

   The classifiers and traffic conditioning elements described above
   can be combined into traffic conditioning blocks (TCBs). The TCB is
   an abstraction of a functional block that may be used to facilitate
   the definition of traffic conditioning functionality.

   A general TCB consists of three stages:

   1. Classifier stage
   2. Metering stage
   3. Action stage

   TCBs are constructed by connecting elements corresponding to these
   stages in any order. It is allowable to omit stages or to
   concatenate multiple stages of the same type. TCB outputs may drive
   additional TCBs (on the same interface or on an egress interface) or
   alternatively, may be directed to a PHB queue on an egress
   interface.










6.1 Example TCB

   The following diagram illustrates an example TCB:



Bernet, Smith, Blake    expires December, 1999                      17


draft-ietf-diffserv-model-00.txt                             June, 1999

                                        -------------> to Queue A
                               -------  |
                               |     |---
                            -->|     |
                            |  |     |---  -------
                            |  -------  |  |     |
                            |   meter   -->|     |-----> discard
                            |              |     |
                            |              -------
                            |              dropper
                            |
                            |
                            |           -------------> to Queue B
    submitted  -------      |  -------  |           ^
     traffic   |  A  |-------  |     |---           |
           --->|  B  |-------->|     |              |
               |  C  |-------  |     |---  -------  |
               |  X  |----  |  -------  |  |     |  |
               -------   |  |   meter   -->|     |---
                 BA      |  |              |     |
              classifier |  |              -------
                         |  |              shaper
                         |  |
                         |  |
                         |  |           -------------> to Queue C
                         |  |  -------  |
                         |  |  |     |---
                         |  -->|     |
                         |     |     |---  -------
                         |     -------  |  |     |
                         |      meter   -->|     |---> to Queue D
                         |                 |     |
                         |                 -------
                         |                re-marker
                         |
                         ----------------------------> to Queue E

             Figure 4 - An Example Traffic Conditioning Block

   This sample TCB might be suitable for an ingress interface at a
   customer/provider interface. A SLA is presumed to have been
   negotiated between the customer and the provider which specifies the
   handling of the customer's traffic by the provider's network. The
   agreement might be of the following form:

   DSCP         PHB       Profile       Non-Conforming Packets
   ----         ---       -------       -------------------------
   001001       PHB1      Profile1      Discarded
   001100       PHB2      Profile2      Shaped to Profile1
   001101       PHB3      Profile3      Re-marked to DSCP 001000

   It is implicit in this agreement that conforming packets are given
   the PHB originally indicated by the packets' DSCP field. It

Bernet, Smith, Blake    expires December, 1999                      18


draft-ietf-diffserv-model-00.txt                             June, 1999

   specifies that the customer may submit packets marked for DSCP
   001001 which will get PHB1 treatment so long as they remain
   conforming to Profile1 and will be discarded if they exceed this
   profile.  Similar contract rules are applied for 001100 and 001101
   traffic.

   In this example, the classification stage consists of a single BA
   classifier. The BA classifier is used to separate traffic based on
   the diffserv service level requested by the customer (as indicated
   by the DSCP in each submitted packet's IP header). We illustrate
   three DSCP filter values: A, B and C. The 'X' in the BA classifier
   indicates 'no match'.

   The metering stage is next. There is a separate meter for each set
   of packets corresponding to DSCPs A, B and C. Each meter uses a
   specific profile as specified in the SLA for the corresponding
   diffserv service level. The meters in this example indicate one of
   two conforming levels, conforming or non-conforming.

   Following the metering stage is the action stage. Packets submitted
   for DSCP A that are deemed non-conforming are discarded. Packets
   that are conforming are passed on to the queue for the corresponding
   PHB.

   Packets submitted for DSCP B that are deemed non-conforming are
   delayed in a shaper until they become conforming. Packets that are
   deemed conforming are allowed to pass directly to the queue for PHB
   B.

   Note that in actual implementations, non-conforming packets will
   cause packets on the same traffic stream that are conforming to be
   delayed in order to maintain per-stream packet ordering. However,
   this is an implementation detail and need not be considered from the
   abstract management perspective.

   Packets submitted for DSCP C and deemed non-conforming are re-marked
   for a less privileged DSCP and are directed to the appropriate PHB
   queue. Packets that are deemed conforming are passed directly to the
   requested PHB queue.

6.2 Formal Representation of TCB

   The following is a formal representation of the interconnection of
   the components of the TCB illustrated in Error! Reference source not
   found.:

   TCB1:

   Classifier1:
   Output A --> Meter1
   Output B --> Meter2
   Output C --> Meter3
   Output X --> QueueE


Bernet, Smith, Blake    expires December, 1999                      19


draft-ietf-diffserv-model-00.txt                             June, 1999


   Meter1:
   Output A --> QueueA
   Output B --> ActionElement1 (dropper)

   Meter2:
   Output A --> QueueB
   Output B --> ActionElement2 (shaper)

   ActionElement2:
   DefaultOutput --> QueueB

   Meter3:
   Output A --> QueueC
   Output B --> ActionElement3 (marker)

   ActionElement3:
   DefaultOutput --> QueueD

6.3 Example TCB to Support Multiple Customers

   The TCB described above can be installed on an ingress interface to
   implement a provider/customer agreement if the interface is
   dedicated to the customer. However, if a single interface is shared
   between multiple customers, then the TCB above will not suffice,
   since it does not differentiate among traffic from different
   customers. Its classification stage uses BA classifiers only.

   The TCB is readily extended to support the case of multiple
   customers per interface, as follows. First, we define a TCB for each
   customer to reflect the agreement with that customer. TCB1, defined
   above is the TCB for customer 1. We add definitions for TCB2 and for
   TCB3 which reflect the agreements with customers 2 and 3
   respectively.

   Finally, we add a fourth TCB, TCB4, which provides a front end to
   separate the traffic from the three different customers. This can be
   illustrated as:


       submitted  +-----+
        traffic   |  A  |--------> TCB1
              --->|  B  |--------> TCB2
                  |  C  |--------> TCB3
                  |  X  |--------> ActionElement4 (dropper)
                  +-----+
                   TCB4

             Figure 5 - An Example Multi-Cusomer Front End TCB

   A formal representation of this multi-customer TCB might be:

   TCB1:

Bernet, Smith, Blake    expires December, 1999                      20


draft-ietf-diffserv-model-00.txt                             June, 1999

   (as defined above)

   TCB2:
   (similar to TCB1, perhaps with different numeric parameters)

   TCB3:
   (similar to TCB1, perhaps with different numeric parameters)

   TCB4:

   Classifier2:
   Output A --> TCB1
   Output B --> TCB2
   Output C --> TCB3
   Output X --> ActionElement4 (dropper)

   Where Classifier2 is defined as follows:

   Classifier2:
   Filter1:     output A
   Filter2:     output B
   Filter3:     output C
   No Match:    output X

   and the filters, based on each customer's source MAC address are
   defined as follow:

   Filter1:
   Type:        MacAddress
   SrcValue:    01-02-03-04-05-06 (source MAC address of customer 1)
   SrcMask:     FF-FF-FF-FF-FF-FF
   DestValue:   00-00-00-00-00-00
   DestMask:    00-00-00-00-00-00

   Filter2:
   (similar to Filter1 but with customer 2's source MAC address as
   SrcValue)

   Filter3:
   (similar to Filter1 but with customer 3's source MAC address as
   SrcValue)

   In this example, TCB4 separates traffic submitted from different
   customers based on the source MAC address in submitted packets.
   Those packets with recognized source MAC addresses are passed to the
   TCB implementing the agreement with the corresponding customer.
   Those packets with unrecognized source MAC addresses are passed to a
   dropper.

   TCB4 has a classification stage and an action element stage (it is
   used only for unrecognized traffic) i.e. all actions are the default
   which is to pass through unchanged. Its outputs drive either the
   dropper action element or additional TCBs.

Bernet, Smith, Blake    expires December, 1999                      21


draft-ietf-diffserv-model-00.txt                             June, 1999


6.4 TCBs Supporting Microflow-based Services

   The TCB illustrated above describes a TC configuration that might be
   suitable for enforcing a SLA at a router's ingress. It assumes that
   the customer marks its own traffic for the appropriate service
   level. It then limits the rate of aggregate traffic submitted at
   each service level, thereby protecting the resources of the diffserv
   network. It does not mark the customer's packets, nor does it
   provide any isolation between the customer's individual microflows.

   Next we present a TC configuration that offers additional
   functionality to the customer. It recognizes individual customer
   microflows and marks each one independently. It also isolates the
   customer's individual microflows from each other in order to prevent
   a single microflow from seizing an unfair share of the resources
   available to the customer at a certain service level. This is
   illustrated in Figure 6 below:


                  -------   -------
                  |     |   |     |--------------->
               -->|     |-->|     |     -------
     -------   |  |     |   |     |---->|     |
     |     |----  -------   -------     -------
   ->|     |----  marker     meter      dropper
     |     |-- |  -------   -------
     ------- | |  |     |   |     |--------------->
       MF    | -->|     |-->|     |     -------
     class.  |    |     |   |     |---->|     |
             |    -------   -------     -------
             |    marker     meter      dropper
             |    -------   -------
             |    |     |   |     |--------------->
             |--->|     |-->|     |     -------
             |    |     |   |     |---->|     |
             |    -------   -------     -------
             |    marker     meter      dropper
             |       .         .     .
             V       V         V     V

       Figure 6 - An Example of a Marking and Traffic Isolation TCB

   Traffic is first directed to an MF classifier which classifies
   traffic based on miscellaneous classification criteria, to a
   granularity sufficient to identify  individual customer microflows.
   Each microflow can then be marked for a specific DSCP (in this
   particular example we assume that one of two different DSCPs is
   marked). The metering stage limits the contribution of each of the
   customer's microflows to the service level for which it was marked.
   Packets exceeding the allowable limit for the microflow are dropped.

   The TCB would be formally specified as follows:

Bernet, Smith, Blake    expires December, 1999                      22


draft-ietf-diffserv-model-00.txt                             June, 1999


TCB1:
   Classifier1: (MF)
   Output A --> Marker1
   Output B --> Marker2
   Output C --> Marker3
   . . .

   Marker1 --> Meter1
   Marker2 --> Meter2
   Marker3 --> Meter3

   Meter1:
   Output A --> TCB2
   Output B --> ActionElement1 (dropper)

   Meter2:
   Output A --> TCB2
   Output B --> ActionElement2 (dropper)

   Meter3:
   Output A --> TCB2
   Output B --> ActionElement3 (dropper)

   The actual traffic element declarations are not shown here.

   Traffic is either dropped by TCB1 or emerges marked for one of two
   DSCPs. This traffic is then passed to TCB2, illustrated below:

                  -------
                  |     |--------------->
               -->|     |     -------
     -------   |  |     |---->|     |
     |     |----  -------     -------
   ->|     |       meter      dropper
     |     |---|  -------
     -------   |  |     |--------------->
       BA      -->|     |     -------
     classifier   |     |---->|     |
                  -------     -------
                   meter      dropper

                     Figure 7 - Additional Example TCB

   TCB2 would be formally specified as follows:

   Classifier2: (BA)
   Output A --> Meter10
   Output B --> Meter11

   Meter10:
   Output A --> PHBQueueA
   Output B --> ActionElement10 (dropper)

Bernet, Smith, Blake    expires December, 1999                      23


draft-ietf-diffserv-model-00.txt                             June, 1999


   Meter11:
   Output A --> PHBQueueB
   Output B --> ActionElement11 (dropper)

7. Queuing Components

   Queuing components are the final conceptual components of the model
   of a diffserv router before packets leave a device. The queuing
   behaviours implemented on an egress interface are modeled as a set
   of inter-dependent queues that are serviced by a queuing algorithm
   with certain parameters and profiles. In particular, the scheduling
   parameters may be any of the Profile types defined for TC elements
   above e.g. SimpleTokenBucket, AverageRate, ExpWeightedMovingAvg.

   QueueSet1:
   Type:        QueueSet
   MaxSustRate: 100 Mbps
   MinGuarRate: 20 Mbps
   Interface:   ifIndex

   - guaranteed buffer pool for this queue set (?)

   QueueA:
   Type:        Queue
   QueueSet:    QueueSet1
   Profile:     Profile1
   MinGuarRate: 2 Mbps
   QueueDepth:  200 kbytes
   Priority:    5

   QueueB:
   Type:        Queue
   QueueSet:    QueueSet1
   Profile:     Profile2
   MinGuarRate: 2 Mbps
   QueueDepth:  200 kbytes
   Priority:    3

   - guaranteed buffer pool for each queue (?)


   <Editor's note: this set of parameters is a strawman for comment>

8. Monitoring

   Generally, it should be possible to retrieve the TCTs and similar
   tabular representations of the different diffserv router components.
   It should be possible to monitor the count of packets submitted to
   each TC element and the disposition of the packet (which of the
   element outputs it was directed to).




Bernet, Smith, Blake    expires December, 1999                      24


draft-ietf-diffserv-model-00.txt                             June, 1999

   In the case of the installation in a router of packet filters that
   conflict, it must be possible to determine the relative precedence
   of the filters as implemented by the router.

9. Initial State

   (TBD)

   <should we discuss here the assumed initial state of a diffserv
   router?>

10. Security Considerations

   <add here>

11. References

   [DSARCH] Carson, M., Weiss, W., Blake, S., Wang, Z., Black, D.,
   Davies, E., "An Architecture for Differentiated Services", RFC 2475,
   December 1998

   [DSFWK] Davies, E., Keshav, S., Verma, D., Carlson, M., Ohlman, B.,
   Blake, S., Bernet, Y., Binder, J., Wang, Z., Weiss, W., "A Framework
   for Differentiated Services", Internet Draft, February 1999
   http://www.ietf.org/internet-drafts/draft-ietf-diffserv-framework-
   02.txt

   [E2E] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L.,
   Nichols, K., Speer, M., Braden, R., Davie, B., "Integrated Services
   Operation over Diffserv Networks", Internet Draft, June 1999,
   www.ietf.org/internet-drafts/draft-ietf-issll-diffserv-rsvp-02.txt

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

   [EF-PHB] Jacobson, V., Nichols, K., and K. Poduri, "An Expedited
   Forwarding PHB", RFC 2598, June 1999.

   [AF-PHB] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski "
   Assured Forwarding PHB Group", RFC 2597, June 1999.

   [DSMIB] Baker, F., Pan, P., Guerin, R., Bernet, Y., "Differentiated
   Service Management Information Base using SMIv2", Internet Draft,
   June 1999. http://www.ietf.org/internet-drafts/draft-ietf-diffserv-
   mib-00.txt

   [SRTCM] Heinanen, J., Guerin, R., "A Single Rate Three Color
   Marker", Internet Draft, May 1999, www.ietf.org/internet-
   drafts/draft-heinanen-diffserv-srtcm-01.txt





Bernet, Smith, Blake    expires December, 1999                      25


draft-ietf-diffserv-model-00.txt                             June, 1999

   [TRTCM] Heinanen, J., Guerin, R., "A Two Rate Three Color Marker",
   Internet Draft, May 1999, www.ietf.org/internet-drafts/heinanen-
   diffserv-trtcm-01.txt

   [GTC] Lin, L., Lo, J., Ou, F., "A Generic Traffic Conditioner",
   Internet Draft, April 1999, www.ietf.org/internet-drafts/draft-lin-
   diffserv-qtc-00.txt

12. Author's Addresses

   Yoram Bernet
   Microsoft
   One Microsoft Way
   Redmond, WA 98052
   Phone: +1 425 936 9568
   E-mail: yoramb@microsoft.com

   Andrew Smith
   Extreme Networks
   3585 Monroe St.
   Santa Clara, CA 95051
   Phone: +1 408 579 2821
   E-mail: andrew@extremenetworks.com

   Steven Blake
   Ericsson Datacom
   3000 Aerial Center Parkway, Suite 140
   Morrisville, NC  27560
   Phone: 919-468-8466 x232
   E-mail: slblake@torrentnet.com
























Bernet, Smith, Blake    expires December, 1999                      26


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