Differentiated ServicesInternet Engineering Task Force                                Y. Bernet
   Internet Draft
Diffserv Working Group                                         Microsoft
   Expires December 1999
INTERNET-DRAFT                                                  A. Smith
   draft-ietf-diffserv-model-00.txt
Expires: April 2000                                     Extreme Networks
                                                                S. Blake
                                                                Ericsson Datacom
                                                            October 1999

                A Conceptual Model for Diffserv Routers

                    draft-ietf-diffserv-model-01.txt

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 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
   http://www.ietf.org/ietf/1id-abstracts.txt.

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

   This document is a product of the Diffserv working group.  Comments
   on this draft should be directed to the Diffserv mailing list
   <diffserv@ietf.org>.

   Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   This draft proposes a conceptual model of Differentiated Services
   (Diffserv) routers for use in the their 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 and configuration.
   This model defines the fundamental queue general functional datapath elements that comprise the Per-Hop Behaviour (PHB) functionality of
   diffserv routers. We propose a formal model for these. We also
   describe parameters
   (classifiers, meters, markers, droppers, monitors, mirrors, muxes,
   queues), their possible configuration parameters, and variables that may how they might
   be used for monitoring
   the operation of the elements described above. There is no attempt
   made interconnected to define realize the packet forwarding behaviours range of diffserv routers
   - these are well classification, traffic
   conditioning, and per-hop behavior (PHB) functionalities described elsewhere in the literature.

Bernet, Smith, Blake    expires December, 1999                       1
   This draft is preliminary and
   [DSARCH].  The model is known intended to be inconsistent in some
   respects with [DSMIB]. abstract and capable of
   representing the configuration parameters important to Diffserv
   functionality for a variety of specific router implementations.  It

Bernet, et. al.            Expires: April 2000                 [page  1]
   is not intended as a guide to correct this prior to hardware implementation.

   This model should serve as a rationale for the
   next version, design of a Diffserv
   MIB [DSMIB], as well for various configuration interfaces (such as to verify full consistency with the
   published diffserv specifications [DSFIELD], [DSARCH], [AF-PHB],
   [EF-PHB].
   [PIB]).  Since these documents are all evolving simultaneously there
   are discrepancies between their current revisions; this should be
   resolved in a future revision of this draft.

Table of Contents

   1.  Introduction

   Differentiated Services (diffserv) [DSARCH, DSFWK] is .................................................  3
   2.  Glossary  ....................................................  4
   3.  Conceptual Model .............................................  6
     3.1  Elements of a set Diffserv Router .............................  6
       3.1.1  Datapath ..............................................  7
       3.1.2  Configuration and Management Interface ................  8
       3.1.3  Optional RSVP Module ..................................  8
     3.2  Hierarchical Model of
   technologies by which network Diffserv Components .................  8
   4.  Classifiers .................................................. 10
     4.1  Definition ................................................ 10
       4.1.1  Filters ............................................... 11
       4.1.2  Overlapping Filters ................................... 12
       4.1.3  Filter Groups ......................................... 12
     4.2  Examples .................................................. 12
       4.2.1  Behavior Aggregate (BA) Classifier .................... 12
       4.2.2  Multi-Field (MF) Classifier ........................... 13
       4.2.3  IEEE802 MAC Address Classifier ........................ 13
       4.2.4  Free-form Classifier .................................. 14
       4.2.5  Other Possible Classifiers ............................ 14
     4.3  MPLS ...................................................... 15
   5.  Meters ....................................................... 15
     5.1  Definition ................................................ 15
     5.2  Examples .................................................. 16
       5.2.1  Average Rate Meter .................................... 16
       5.2.2  Exponentially Weighted Moving Average (EWMA) Meter .... 17
       5.2.3  Two-Parameter Token Bucket Meter ...................... 17
       5.2.4  Multi-Stage Token Bucket Meter ........................ 18
       5.2.5  Null Meter ............................................ 19
   6.  Action Elements .............................................. 19
     6.1  Marker .................................................... 19
     6.2  Dropper ................................................... 20
     6.3  Shaper .................................................... 20
     6.4  Mirroring Element ......................................... 20
     6.5  Multiplexor ............................................... 20
     6.6  Enqueueing Element ........................................ 20
     6.7  Monitor ................................................... 21
     6.8  Null Action ............................................... 21
   7.  Queues ....................................................... 21
     7.1  Queue Sets and Scheduling ................................. 21
     7.2  Shaping ................................................... 23
   8.  Traffic Conditioning Blocks (TCBs) ........................... 23
     8.1  An Example TCB ............................................ 24

Bernet, et. al.            Expires: April 2000                 [page  2]
     8.2  An Example TCB to Support Multiple Customers .............. 27
     8.3  TCBs Supporting Microflow-based Services .................. 28
   9.  Open Issues .................................................. 31
  10.  Security Considerations ...................................... 31
  11.  Acknowledgments .............................................. 31
  12.  References ................................................... 32
  Appendix A.  Simple Token Bucket Definition ....................... 33

1. Introduction

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

   The advantage of such a scheme is that many traffic streams can be
   aggregated to one of a small number of behaviour behavior 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
   core of the Diffserv network since QoS is invoked on a packet-by-packet packet-by-
   packet basis.

   Although diffserv itself does not define the

   The Diffserv architecture enables a variety of possible services that
   which could be deployed in a
   diffserv network can provide, its successful deployment depends on
   the ability to use the technology to provide services. network.  These services are reflected
   to customers at the edges of the diffserv Diffserv network in the form of a
   Service Level Specification (SLS) [DSFWK]. [DSTERMS].  The ability to provide
   these services depends on the availability of cohesive management and
   configuration tools that can be used to provision and monitor a set
   of diffserv Diffserv routers in a coordinated manner.  To facilitate the
   development of such configuration and management tools it is helpful
   to define a conceptual model of a diffserv Diffserv router that abstracts
   away implementation details of diffserv particular Diffserv routers from the management tools used to manage
   them.
   parameters of interest for configuration and management.  The purpose
   of this draft is to define this conceptual such a model.

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

   This document is not intended in any way to constrain or to dictate
   implementations
   the implementation alternatives of diffserv 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,
   configuration and management tools will more readily be able to
   configure and manage networks incorporating diffserv Diffserv routers of

Bernet, et. al.            Expires: April 2000                 [page  3]
   various implementations.

2. Organization of this Document

Bernet, Smith, Blake    expires December, 1999                       2
   In Section Sec. 3 we start by describing the basic high-level functional
   blocks
   elements of a diffserv Diffserv router and then providing a block diagram and describe the various
   components.  We then focus on the diffserv-
   specific Diffserv-specific components of
   the router and describe a hierarchical management model for these.

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

   In Section 6, Sec. 6 we discuss action elements.  In Sec. 7 we discuss the
   basic queueing elements and their functional behaviors (e.g.,
   shaping).

   In Sec. 8, we show how the basic classification classification, meter, action, and traffic
   conditioning
   queueing elements can be combined to build modules called Traffic
   Conditioning Blocks (TCBs).

   In Section 7, Sec. 9 we discuss the basic queuing components.

   In Section 8, open issues with this document and in Sec. 10 we
   discuss those parameters that it must be possible
   to monitor for the purposes security concerns.

   Appendix A discusses token bucket implementation details.

2.  Glossary

   Some of managing the terms used in this draft are defined in [DSARCH] and in
   [DSTERMS].  We define a diffserv router.

3. Elements few of them here again only to provide
   additional detail.

   Buffer        An algorithm used to determine whether an arriving
   management    packet should be stored in a Diffserv Router

   In this section we introduce queue, or discarded.  This
   algorithm     decision is usually a block diagram function of the instantaneous or
                 average queue occupancy, but also may be a function of
                 the aggregate queue occupancy in a diffserv router queue set, or of
                 other parameters.

   Classifier    A functional datapath element which consists of filters
                 which select packets based on the content of packet
                 headers or other packet data, and/or on implicit or
                 derived attributes associated with the packet, and describe
                 forwards the various components illustrated. Note that packet along a particular datapath within
                 the
   functions router.  A classifier splits a single incoming
                 traffic stream into multiple outgoing ones.

   Enqueueing    The process of executing a diffserv core router are likely buffer management algorithm
                 to determine whether an arriving packet should be
                 stored in a much
   simplified queue.

   Filter        A set of these components: (wildcard/prefix/masked/range/exact)
                 conditions on the model we present here components of a packet's
                 classification key.  A filter is
   intended said to cover the case match only if
                 each condition is satisfied.

Bernet, et. al.            Expires: April 2000                 [page  4]
   Mirroring     A functional datapath element which makes one or more
   element       copies 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 packet and forwards them on distinct
                 datapaths; for example to a monitoring port.

   Monitor       A functional datapath element which increments an octet
                 and a packet counter for every packet which passes
                 through it.  Used for collecting statistics.

   Multiplexer   A functional datapath element that merges multiple
   (Mux)         traffic conditioning components.
   3. Certain combinations of streams (datapaths) into a single traffic conditioning components.
   4. Queuing components.

    The components and combinations
                 stream (datapath).

   Non-work      A property of components described in this
    document form building blocks a scheduling algorithm such that need to be manageable it does
   conserving    not necessarily service a packet if available at every
                 transmission opportunity.

   Queue         A storage location for packets awaiting transmission or
                 processing by
    diffserv management tools. One of the goals of next functional element in the data-
                 path.  The queues represented in this document is to
    show how a model of a diffserv device can are
                 abstract elements that may be built up out of these
    component blocks. This model is implemented by multiple
                 physical queues in series and/or in parallel in the form of a connected acyclic
    directional graph
                 specific implementation.  Note that describes the traffic conditioning behaviour we assume that any particular data packet will experience when submitted to
    the diffserv router.

    It a
                 queue is anticipated that these building blocks may also be used serviced such as to preserve the basis required
                 ordering constraint for each Ordering Aggregate (OA)
                 it queues [DSTERMS].  This can be achieved by a diffserv MIB FIFO
                 (first in, first out) service policy or by other such specific device
    configuration mechanisms.

Bernet, Smith, Blake    expires December, 1999                       3

3.2 Block Diagram

   The following diagram illustrates means
                 (e.g., multiple FIFOs exclusively servicing particular
                 OAs).

   Queue set     A set of queues which are serviced by a scheduling
                 algorithm and which may share a buffer management
                 algorithm.

   Scheduling    An algorithm which determines which queue of a queue
   algorithm     set to service next.  This may be based on the major functional blocks relative
                 priority of the queues, or on 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, weighted fair bandwidth
                 sharing policy, or some other policy.  A scheduling
                 algorithm may be either work-conserving or non-work-
                 conserving.

   Shaping       The process of delaying packets within a traffic stream
                 to cause it to conform to some defined traffic profile.
                 Shaping can be implemented using a queue serviced by a
                 non-work conserving scheduling algorithm.

   Traffic       A logical datapath element consisting of a number of
   Conditioning  other functional datapath elements interconnected in
   Block (TCB) represents   such a
   combination way as to perform a specific set 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 traffic
                 conditioning functions on an incoming traffic stream.
                 A TCB can be thought of as a "black box" with a single
                 input and egress interface are
   illustrated at the center output.

Bernet, et. al.            Expires: April 2000                 [page  5]
   Work          A property of the diagram. a scheduling algorithm such that it
   conserving    services a packet if available at every transmission
                 opportunity.

3.  Conceptual Model

   In actual router
   implementations, there may be an arbitrary number this section we introduce a block diagram of inbound a Diffserv router and
   outbound interfaces interconnected by
   describe the routing core. The various components illustrated.  Note that a Diffserv
   core router is assumed to include only a subset of interest on these interfaces are components:
   the traffic
   classifiers, model we present here is intended to cover the traffic conditioning components (TC) case of both
   Diffserv edge and the
   queuing components that support the Per-Hop Behaviour (PHB)
   [DSARCH]. These are the fundamental components comprising core routers.

3.1  Elements of a diffserv
   router and will be Diffserv Router

   The conceptual model we define includes abstract definitions for the focal point
   following:

   o  The basic traffic classification components.

   o  The basic traffic conditioning components.

   o  Certain combinations 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
   Provisioned parameters are primarily classification rules, PHB and
   TC configuration parameters. conditioning
      components.

   o  Queueing components.

   The network administrator interacts
   with the diffserv components and combinations of components described in this
   document form building blocks that need to be manageable by 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 tools.  One of QoS requirements [E2E]. The example
   discussed here uses the RSVP protocol. Snooping goals of RSVP messages may
   be used, for example, this
   document is to learn show 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 model of
   admission control to diffserv-based services or they may use these
   requests to trigger provisioning changes for a flow-aggregation Diffserv device can be built
   using these component blocks.  This model is in the diffserv network. A flow-aggregation in this context might be
   equivalent to form of a diffserv BA or it may be more fine-grained, relying
   on a MF classifier. Note that the conceptual model
   connected directed acyclic graph (DAG) of such a router
   starts to look the same as a Integrated Services (intserv) router in
   its component makeup [E2E].

   Note functional datapath
   elements that a RSVP component of a diffserv router, if present, might
   be active only in describes the control plane traffic conditioning and not in queueing
   behaviors that any particular packet will experience when forwarded
   to 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 router.

   The following diagram illustrates the diffserv specific major functional components blocks 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
                  +------------+     +-------+     +------------+
          ------->| a
   Diffserv router:

Bernet, et. al.            Expires: April 2000                 [page  6]
               +---------------+
               |  Diffserv     |
        Mgmt   | configuration |
      <----+-->| & management  |------------------+
      SNMP,|   |  interface    |                  |
      COPS |   +---------------+                  |
      etc. |        |                             |
           |        |                             |
           |        v                             v
           |   +-------------+   +---------+   +-------------+
      data |   | ingress   |---->|       |---->| i/f |   |         |   | egress    |--->
                  |(class.,TC) i/f  |
      -------->|   class.,   |-->| routing |-->|   class.,   |---->
           |   |     TC,     |   |  core   |   |     TC,     |
           |   |   queueing  |   |         |   |   queueing  |
           |   +-------------+   +---------+   +-------------+
           |        ^                             ^
           |        |     |(queuing,TC)|
                  +------------+     |routing|     +------------+                             |
           |
                  +------------+        |                             |     +------------+
          <-------|  egress    |<----|       |<----|  ingress   |<---
                  |(queuing,TC)|     +-------+     |(class.,TC)
           |   +------------+                     |
           +-->|    RSVP    |                     |
      -------->| (optional) |---------------------+
        RSVP   +------------+
        cntl
        msgs

      Figure 1 - Traffic Conditioning and Queuing

   This diagram illustrates two diffserv router interfaces, each having
   an 1:  Diffserv Router Major Functional Blocks

3.1.1  Datapath

   An ingress interface, routing core, 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
   At interface are
   illustrated at the top level, center of the diagram.  In actual router manager manages interfaces. Each
   interface consists of
   implementations, there may be an arbitrary number of ingress component and an
   egress component.
   An ingress component contains TC components. An egress component
   contains PHB components interfaces interconnected by the routing core.  The routing
   core element serves as an abstraction of a router's normal routing
   and TC components. (There may be special
   cases in which switching functionality.  The routing core moves packets between
   interfaces according to policies outside the scope of Diffserv.  The
   actual queueing delay and packet loss behavior of a router implements PHB components on an ingress
   interface. This model specific router's
   switching fabric/backplane is readily extensible to reflect such an
   implementation. However, we have chosen not to do so in this case.) modeled by the routing core; these
   should be modeled using the functional elements described later.  The
   routing core should be thought of as an infinite bandwidth, zero-
   delay backplane connecting ingress and egress interfaces.

   The TC components of interest on each interface the ingress/egress interfaces are described by a the
   traffic classifiers, traffic conditioning table (TCT) corresponding to (TC) components, and the interface. The TCT
   describes
   queueing components that support Diffserv traffic classification and conditioning elements and how
   they
   per-hop behaviors [DSARCH].  These are combined to provide the interface's traffic conditioning
   functionality. Certain traffic conditioning elements may be grouped
   into traffic conditioning blocks (TCBs).

   PHB fundamental components contain queues
   comprising a Diffserv router and will be the enqueuing focal point of our
   conceptual model.

Bernet, et. al.            Expires: April 2000                 [page  7]

3.1.2  Configuration and dequeuing
   algorithms that serve them. Queues Management Interface

   Diffserv operating parameters are each independently
   parameterized. There monitored and provisioned through
   this interface.  Monitored parameters include statistics regarding
   traffic carried at various Diffserv service levels.  These statistics
   may also be parameters defining relationships
   between PHBs.

4. Classification Elements

   Classification is a necessary function important for any device that treats
   certain traffic differently from other traffic. The very nature of a
   diffserv router is that it treats accounting purposes and/or for tracking
   compliance to traffic differentially. Therefore, conditioning specifications (TCSs) [DSTERMS]
   negotiated with customers.  Provisioned parameters are primarily
   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 rules, TC and generate logically separate
   traffic streams as output. Packets from the input stream are sorted
   into various output streams depending on the contents of PHB configuration parameters.  The
   network administrator interacts with the packet Diffserv configuration and possibly on
   management interface via one or more management protocols, such as
   SNMP or COPS, or through other sources of information e.g. input sub-channel
   number. The various types of classifiers are described router configuration tools such as
   serial terminal or telnet consoles.

3.1.3 Optional RSVP Module

   Diffserv routers may snoop or participate in the
   following sections.

4.1 Behaviour Aggregate (BA) Classifier either per-microflow or
   per-flow-aggregate signaling of QoS requirements [E2E].  The simplest diffserv classifier is a behaviour aggregate (BA)
   classifier. A BA classifier example
   discussed here uses only the diffserv codepoint (DSCP)
   in RSVP protocol.  Snooping of RSVP messages may
   be used, for example, to learn how to classify traffic without
   actually participating as a packet's IP header RSVP protocol peer.  Diffserv routers may
   reject or admit RSVP reservation requests to determine the logical output stream provide a means of
   admission control to
   which Diffserv-based services or they may use these
   requests to trigger provisioning changes for a flow-aggregation in
   the packet should Diffserv network.  A flow-aggregation in this context might be directed.

4.2 Multi-Field (MF) Classifier

   Another type of classifier is
   equivalent to a multi-field (MF) classifier. This
   classifies packets based on one Diffserv BA or it may be more fields in the packet header
   other than the DSCP. A common type of MF classifier is fine-grained, relying
   on a 5-tuple MF classifier [DSARCH].  Note that classifies based on the five IP header fields conceptual model 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
   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. router starts to look the incoming channel number on same as a
   channelized interface) or on information derived from Integrated Services (intserv)
   router in its component makeup [E2E].

   Note that a different
   classification operation (e.g. the outgoing interface determined by RSVP component of a Diffserv router, if present, might
   be active only in the route lookup operation). We do control plane and not discuss these further here.

4.4 Filters

   Classifiers are parameterized by filters 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 output streams. For
   example, PHBs in handling data traffic.

3.2  Hierarchical Model of Diffserv Components

   We focus on the following classifier separates traffic into one Diffserv specific functional components of
   three output streams the
   router: the classification, traffic conditioning, and queueing
   functionality.  The diagram below is based on two filters:

          Filter Matched        Output Stream
          --------------       ---------------
               1 the larger block
   diagram shown above:

Bernet, et. al.            Expires: April 2000                 [page  8]
             Interface A
               2                        Interface B
            no match                  C

   Where filters 01
          +-------------+     +---------+     +-------------+
          | ingress i/f |     |         |     | egress i/f  |
          |   class.,   |     |         |     |   class.,   |
      --->|   meter,    |---->|         |---->|   meter,    |--->
          |   action,   |     |         |     |   action,   |
          |   queueing  |     |         |     |   queueing  |
          +-------------+     | routing |     +-------------+
                              |  core   |
          +-------------+     |         |     +-------------+
          | egress i/f  |     |         |     | ingress i/f |
          |   class.,   |     |         |     |   class.,   |
      <---|   meter,    |<----|         |<----|   meter,    |<---
          |   action,   |     |         |     |   action,   |
          |   queueing  |     +---------+     |   queueing  |
          +-------------+                     +-------------+

      Figure 2.  Traffic Conditioning and 02 are defined to Queueing Elements

   This diagram illustrates two Diffserv router interfaces, each having
   an ingress and an egress component.  It shows classification, meter,
   action, and queueing elements which might be the following BA filters:

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

   A filter consists of a set of conditions instantiated on the component values of each
   interface's ingress and egress component.  The TC functionality is
   implemented by a classification key. In the BA classifier example above, the
   classification key consists combination of one packet header field, the DSCP,
   and both Filter1 classification, action, meter, and Filter2 specify exact-match conditions
   queueing elements.  We show equivalent functional elements on both
   the
   value ingress and egress components of an interface because we expect
   an N-port router to display 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 same Diffserv capabilities as a whole set
   network of possible component conditions
   including exact, prefix, range, wildcard and masked matches. 2-port routers interconnected by LAN media [DSMIB].  Note
   that ranges can be represented (maybe less efficiently) as a set of
   prefix matches and it is not mandatory that prefix matches are just a special case each of
   masked matches.

   In these functional elements be
   implemented on both ingress and egress components; it is dependent on
   the case of service requirements on a MF classifier, particular interface on a particular
   router.  Further, we wish to point out that by showing these elements
   on both ingress and egress components we do not mean to imply that
   they must be implemented in this way in a specific router.  For
   example, a router may implement all shaping and PHB queueing on the
   interface egress component, or may instead implement it only on the
   ingress component.  Further, the classification key consists of needed to map a
   number of
   packet header fields.  The filter to an egress component queue (if present) need not be
   implemented on the egress component but instead may specify a different
   condition for each key be implemented on
   the ingress component, as illustrated in with the example
   below packet passed through the routing
   core with in-band control information to allow for egress queue
   selection.

   From 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
   In this example, configuration and management perspective, the fourth octet of following
   hierarchy exists:

   At the destination IPv4 address
   and top level, the source TCP port are 'don't cares'.

4.5 Diagram network administrator manages interfaces.  Each
   interface consists of a Classifier

   We use the following diagram to illustrate a an ingress component and an egress component.
   Each component may contain classifier, where action, meter, and queueing
   elements.

Bernet, et. al.            Expires: April 2000                 [page  9]
   At the
   outputs next level, the network administrator manages groups of
   functional elements interconnected in a DAG.  These elements are to be plumbed
   organized in self-contained Traffic Conditioning Blocks (TCBs) which
   are used to succeeding TC elements:

            unclassified            classified
              traffic                traffic
                     ----------- implement some desired network policy (see Sec. 8).  One
   or more TCBs may be instantiated on each ingress or egress component,
   may be connected in series, and/or may be connected in a
   parallel configuration on the multiple outputs of a classifier.
   We define the TCB to optionally include classification and queueing
   elements so as to allow for rich functionality.  A TCB can be thought
   of as a "black box" with a single input and a single output (on the
   main data path).  TCBs can be constructed out of a DAG of other TCBs,
   recursively.  We do not assume the same TCB configuration on every
   interface (ingress or egress).

   At the lowest level are individual functional elements, each with
   their own configuration parameters and management counters and flags.

4.  Classifiers

4.1  Definition

   Classification is performed by a classifier element.  Classifiers are
   1:N (fan-out) devices: they take a single traffic stream as input and
   generate N logically separate traffic streams as output.  Classifiers
   are parameterized by filters and output streams.  Packets from the
   input stream are sorted into various output streams by filters which
   match the contents of the packet or possibly match other attributes
   associated with the packet.  Various types of classifiers are
   described in the following sections.

   We use the following diagram to illustrate a classifier, where the
   outputs connect to succeeding functional elements:

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

      Figure 2 - 3.  An Example Classifier

   Note that an we allow a mux (see Sec. 6.5) before the classifier to
   allow input from multiple traffic streams.  For example, if multiple
   ingress sub-interfaces feed through a single classifier then the
   interface number can also be considered as an
   input to the classifier if by the classifier is modeled as accepting
   packets from multiple input ports - this optimisation a packet
   attribute and be included in the packet's classification key.  This
   optimization 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  Another possible packet attribute could 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 an integer
   representing the BGP community string associated with the packet's
   best-matching route.

   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 separates traffic into one of 6-bit DSCP {value,
   mask} pairs:

   Classifier1:
   Filter3: three output
   streams based on three filters:

      Filter Matched        Output Stream
      --------------       ---------------
      Filter1                    A
   Filter4:     output
      Filter2                    B
   No Match:    output
      Filter3 (no match)         C

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

   <note: can IPv4

   Where Filters1 and IPv6 BA classifiers Filter2 are defined to be modeled the same as each
   other?>

4.6.4 IEEE802 MAC Address Classifiers following BA filters
   ([DSARCH], see Sec. 4.2.1 ):

      Filter        DSCP
      ------       ------
        1           101010
        2           111111
        3           ****** (wildcard)

4.1.1  Filters

   A MacAddress classifier is parameterised by filter consists of a 6-byte {value, mask}
   pair for either source or destination MAC address.l set of conditions on the component values of
   a packet's classification key (the header values, contents, and
   attributes relevant for example, classification).  In 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
   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 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.  Filter3 is made up 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 set of possible component conditions including
   exact, prefix, range, masked, and wildcard matches.  Note that ranges
   can be represented (with less efficiency) as a set of user definable
   arbitrary filters prefixes and
   that prefix matches are just a special case of both masked and range
   matches.

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

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

   In this example, the fourth octet of {bit-field size, offset (from head the destination IPv4 address
   and the source TCP port are wildcard or "don't cares".

4.1.2  Overlapping Filters

   Note that it is easy to define sets of packet), mask}:

   Classifier3:
   Filter6:     output A
   Filter7:     output B
   No Match:    output C overlapping filters in a
   classifier.  For example:

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

   Filter7:   Masked-DSCP   Type:        FreeForm
   SizeBits:    12 bits
   Offset:      16 bytes   Masked-DSCP
      Value:       100100000000  111000        Value:  000111 (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
   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   111000        Mask:   000111 (binary)

   A packet containing the DSCP = 111111 cannot be uniquely classified by
   this set pair of filters and so a precedence must be established between
   Filter1
   Filter5 and Filter2 Filter6 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. 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 configuration and management protocol
   protocols 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

   An unambiguous classifier requires that every possible classification
   key match at least one filter (including the elements wildcard default), and
   that can any ambiguity between overlapping filters be
   combined to provide resolved by
   precedence.

4.1.3  Filter Groups

   Filters may be logically combined.  For example, consider the traffic-conditioning functionality
   described. These include meters
   following DestMacAddress filter:

      Filter7:
      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 various action elements.

5.1 Meters

   Metering Filter7:         output A
      Filter2 and Filter7:         output B
      Default (wildcard) filter:   output C

4.2  Examples

4.2.1  Behaviour Aggregate (BA) Classifier

   The simplest Diffserv classifier is a behavior aggregate (BA)
   classifier [DSARCH].  A BA classifier uses only the function of monitoring the arrival times of packets
   on Diffserv
   codepoint (DSCP) in a traffic packet's IP header to determine the logical
   output stream and determining to which the level of conformance of each packet to a profile. Diffserv network providers may offer services
   to customers based should be directed.  We allow only
   an exact-match condition on a temporal profile within which the customer

Bernet, Smith, Blake    expires December, 1999                      11
   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 field because the assigned DSCP
   values have no structure, and billing applications.

   Meters therefore no subset of DSCP bits are parameterized by
   significant.

   The following defines a temporal profile and by conformance
   levels.

5.1.1 Types of Meters

5.1.1.1 Average Rate Meter

   An example possible BA filter:

      Filter8:
      Type:   BA
      Value:  111000

4.2.2  Multi-Field (MF) Classifier

   Another type of a very simple meter classifier is an average rate meter. a multi-field (MF) classifier [DSARCH].
   This
   type of meter measures the average rate at which classifies packets are
   submitted to it over a specified averaging time.

   An average rate profile may take based on one or more fields in the following form:

   Average Rate: 10 packets per second
   Averaging Interval: 1 second packet
   header (including the DSCP).  A meter measuring against this profile would continually maintain common type of MF classifier is a
   count 6-
   tuple classifier that indicates the total number of packets arriving between
   time T (now) classifies based on six IP header fields
   (destination address, source address, IP protocol, source port,
   destination port, and time T-1 second. So long DSCP).  MF classifiers may classify on other
   fields such as an arriving packet does
   not push the count over 10, the packet would MAC addresses, VLAN tags, link-layer traffic class
   fields or other higher-layer protocol fields.

   The following defines a possible MF filter:

      Filter9:
      Type:              IPv4-6-tuple
      IPv4DestAddrValue: 0
      IPv4DestAddrMask:  0.0.0.0
      IPv4SrcAddrValue:  172.31.8.0
      IPv4SrcAddrMask:   255.255.255.0
      IPv4DSCP:          28
      IPv4Protocol:      6
      IPv4DestL4PortMin: 0
      IPv4DestL4PortMax: 65535
      IPv4SrcL4PortMin:  20
      IPv4SrcL4PortMax:  20

   A similar type of classifier can be deemed conforming.
   Any packet that pushes defined for IPv6.

4.2.3 IEEE802 MAC Address Classifier

   A MacAddress filter is parameterized by a 6-byte {value, mask} pair
   for either source or destination MAC address.  For example, the count over 10, would be deemed non-
   conforming. Thus, this meter deems
   following classifier sends packets matching either DA =
   01-02-03-04-05-06 or SA = 00-E0-2B-XX-XX-XX to correspond to one output A:

      Classifier1:
      Filter10:     output A
      Filter11:     output A
      Default:      output B
      Filter10:
      Type:        DestMacAddress
      Value:       01-02-03-04-05-06 (hex)
      Mask:        FF-FF-FF-FF-FF-FF (hex)

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

4.2.4  Free-form Classifier

   A Free-form classifier is made up of
   two conformance levels - conforming or non-conforming.

5.1.1.2 Exponential Weighted Moving Average Meters

   The EWMA form a set of meter is easy to implement in silicon and user definable
   arbitrary filters each made up of {bit-field size, offset (from head
   of packet), mask}:

      Classifier2:
      Filter12:    output A
      Filter13:     output B
      Default:     output C

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

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

   Free-form filters can be
   parameterised as follows:

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

  For combined into filter groups to form very
   powerful filters.

4.2.5  Other Possible Classifiers

      Classifier3:
      Filter14:     output A
      Filter15:     output B
      Default:      output C

      Filter14:
      Type:        IEEEPriority
      Value:       100 (binary)
      Mask:        101 (binary)
      Filter15:
      Type:        IEEEVLAN
      Value:       100100000000 (binary)
      Mask:        111111111111 (binary)

   Classification may be performed based on implicit information
   associated with 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 channel number on a small fixed sampling
   interval, Delta. Any packet that arrives and pushes the average rate
   over
   channelized interface) or on information derived from a predefined rate AverageRate different
   non-Diffserv classification operation (e.g. the outgoing interface
   determined by the route lookup operation).  Other vendor-specific
   filter formats are possible.  We do not discuss these further here.

4.3  MPLS

   It is deemed non-conforming.

5.1.1.3 Token Bucket Meters

Bernet, Smith, Blake    expires December, 1999                      12
   A more sophisticated meter might measure conformance to a token
   bucket (TB) profile. A TB profile generally has three parameters, possible for an
   average rate, MPLS label-switched router (LSR) to function as
   a peak rate Diffserv router [MPLSDS].  In this case the IP header is not
   visible for inspection and a burst size. TB meters compare all header classification must be
   performed on the
   arrival rate of packets to MPLS label, and in the average rate specified by event of shim encapsulation,
   on the TB
   profile. Logically, byte tokens accumulate 3-bit EXP field in addition.  In general a bucket MPLS classification
   filter may specify either wildcard- or exact-match conditions for
   either field (but not both wildcard at the
   average rate, up once).  The distinction to a maximum credit which be
   drawn here is the burst size.
   Packets of length L bytes are considered conforming if L tokens that MPLS labels are
   available in dynamically established and torn
   down.  An EXP-only classifier may be statically configured but a
   label or label + EXP classifier must be established dynamically along
   with the bucket at LSP.  In all other respects (except marking) the time of labeled
   packet arrival. Packets are
   allowed to exceed the average rate in bursts up can be treated identically to an unlabeled packet.

5.  Meters

5.1  Definition

   Metering is the burst size,
   so long as they do not exceed function of monitoring the peak rate, at which point arrival times of packets
   of a traffic stream and determining the
   bucket will be drained. Packets which arrive level of conformance of each
   packet 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 pre-established traffic profile.  Diffserv network
   providers may choose to exceed the larger
   burst size are deemed non-conforming. Packets found offer services to exceed customers based on a
   temporal (i.e., rate) profile within which the
   smaller burst size are deemed partially conforming. Packets
   exceeding neither are deemed conforming. Token bucket meters
   designed customer submits
   traffic for diff-serv networks the service.  In this event, a meter might be used to
   trigger real-time traffic conditioning actions (e.g., marking) by
   routing a non-conforming packet through an appropriate next-stage
   action element.  Alternatively, it might also be used for out-of-band
   management functions like statistics monitoring for billing
   applications.

   Meters are described in more detail in
   [SRTCM], [TRTCM] and [GTC]: logically 1:N (fan-out) devices (although a mux can be
   used in some of these references, three
   levels front of conformance a meter).  Meters are discussed in terms parameterized by a temporal
   profile and by conformance levels, each of colors, which is associated with green
   representing conforming, yellow representing partially conforming
   and red representing non-conforming.

5.1.2 Diagram
   a meter's output.  Each output can be connected to another functional
   element.

   Note that this model of a Meter meter differs from that described in
   [DSARCH].  In that description the meter is not a datapath element
   but is instead used to monitor the traffic stream and send control
   signals to action elements to dynamically modulate their behavior
   based on the conformance of the packet.  We find the description here
   more powerful.

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

      unmetered              metered
      traffic                traffic

                         -----------

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

      Figure 3 - 4.  An Example Meter

   In some diffserv Diffserv examples, three levels of conformance are discussed
   in terms of colors, with green representing conforming, yellow
   representing partially conforming conforming, and red representing non-
   conforming.
   conforming [AF-PHB].  These different conformance levels are used to
   trigger different buffer management actions.  Other example meters
   use a binary notion of conformance; in the general case there are 'N' N levels of conformance.

5.1.3 Formal Representations of Meters

5.1.3.1 Simple Token Bucket Meter

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

   Meter1:

Bernet, Smith, Blake    expires December, 1999                      13
   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 supported.  In general there is no constraint on
   the type of functional element following a meter output, but care
   must be taken not to inadvertently configure a datapath that results
   in packet reordering within an OA.

5.2  Examples

   The following is a non-exhaustive list of possible meters.

5.2.1  Average Rate Meter

   Meter4:

   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:

      Meter1:
      Type:                AverageRate
   Profile5:
      Profile1:            output A
      NonConforming:       output B

   Profile5:

      Profile1:
      Type:                AverageRate
      AverageRate:         120 Kbps

Bernet, Smith, Blake    expires December, 1999                      14 KBps
      Delta:               100us

5.1.3.5 Other Vendor-specific Meters

   Other vendor specific meters are also possible.

5.2 Action Elements

   Classifiers               1.0 msec
   A meter measuring against this profile would continually maintain a
   count that indicates the total number of packets arriving between
   time T (now) and meters are generally used to determine time T - 1.0 msecs.  So long as an arriving packet
   does not push the
   appropriate action count over 120 bytes, the packet would be deemed
   conforming.  Any packet that pushes the count over 120 would be
   deemed non-conforming.  Thus, this meter deems packets to apply correspond
   to a packet. one of two conformance levels: conforming or non-conforming.

5.2.2  Exponential Weighted Moving Average (EWMA) Meter

   The set EWMA form 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 meter is easy to simply pass the packet on to a PHB queue.

   Policing is implement in hardware and can be
   parameterized as follows:

      avg_rate(t) = (1 - Gain) * avg_rate(t') +  Gain * rate(t)
      t = t' + Delta

   For a general term for packet arriving at time t:

      if (avg_rate(t) > AverageRate)
         non-conforming
      else
         conforming

   Gain controls the action of preventing a traffic
   stream from seizing more than its share time constant (e.g. frequency response) of resources from what is
   essentially a diffserv
   network. Each of simple IIR low-pass filter.  rate(t) measures the three action elements described may be used to
   police traffic. Markers do so by re-marking submitted packets to
   number of incoming bytes in a
   DSCP small fixed sampling interval, Delta.
   Any packet that is entitled to less network resources. Shapers arrives and
   droppers do so by limiting pushes the average rate at which over a particular traffic
   stream predefined
   rate AverageRate is submitted deemed non-conforming.  An EWMA meter profile
   might look as follows:

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

      Profile2:
      Type:                ExpWeightedMovingAvg
      AverageRate:         25 KBps
      Delta:               10.0 usec
      Gain:                1/16

5.2.3  Two-Parameter Token Bucket Meter

   A more sophisticated meter might measure conformance to the network.

5.2.1 Markers

   Markers set the DSCP in a packet header. Markers may act on unmarked
   packets (submitted with DSCP token
   bucket (TB) profile.  A TB profile generally has two parameters, an
   average token rate, a burst size.  TB meters compare the arrival
   rate of zero) or may re-mark previously
   marked packets. In particular, packets to the model supports average rate specified by the application of
   marking based on a preceding classifier match. The DSCP set TB profile.
   Logically, byte tokens accumulate in a
   packet will determine its subsequent treatment both by any following
   classifier elements within the same node or by other nodes
   downstream in bucket at the diffserv network.

   Markers are parameterized by average rate,
   up to a single parameter - maximum credit which is the six-bit DSCP
   to be marked in packet headers.

5.2.1.1 Formal Representation burst size.  Packets of a Marker

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

   ActionElement1:
   Type:                Marker
   Mark:                010010
5.2.2 Shapers

   Shapers length
   L bytes 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
   Shapers operate by delaying packets that would be deemed non- considered conforming to the shaper's profile. The packet is delayed until such
   time that it becomes conforming. Consider if L tokens are available in the average rate profile
   described previously. In
   bucket at the case that a burst time of 11 packets was
   submitted simultaneously packet arrival.  Packets are allowed to a meter using
   exceed the average rate profile,
   the 11th packet would be deemed non-conforming. In order in bursts up to be
   deemed conforming, the packet would have burst size.  Packets
   which arrive to be delayed by one
   second. Thus, find a shaper parameterized by the average rate profile
   (see section 5.1.1.1) would delay the 11th packet for one second.
   Shapers bucket with insufficient tokens in it are parameterized by a single temporal profile e.g. a token
   bucket.

   Implicit
   deemed non-conforming.  A two-parameter TB meter has exactly two
   possible conformance levels (conforming, non-conforming).  TB
   implementation details are discussed in the definition of a shaper is a notion of a queue Appendix A.

   A two-parameter RB meter profile might look as follows:

      Meter3:
      Type:                SimpleTokenBucket
      Profile3:            output A
      NonConforming:       output B

      Profile3:
      Type:                SimpleTokenBucket
      AverageRate:         100 KBps
      BurstSize:           100 KB

5.2.4  Multi-Stage Token Bucket Meter

   More complicated TB meters might define two burst sizes and a
   queue depth: in order to delay a packet, a shaper must have
   somewhere three
   conformance levels.  Packets found to store exceed the packet and that storage area often has finite
   size. The queue is modeled here as a simple FIFO with a finite
   depth. Packets larger burst size
   are dropped if the depth is exceeded - this is
   considered deemed non-conforming.  Packets found to be an error condition.

5.2.2.1 Uses of Shapers

   Shapers exceed the smaller
   burst size are often used to pre-condition traffic such that packets deemed partially conforming.  Packets exceeding
   neither are not deemed non-conforming by subsequent meters, e.g. conforming.  Token bucket meters designed for
   Diffserv networks are described in
   downstream diffserv nodes. Shapers may also be used to isolate
   certain traffic streams from the effects of other traffic streams more detail in [SRTCM, TRTCM,
   GTC]; in some of
   the same BA. For example, consider the case these references three levels of two traffic streams
   that conformance 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
   discussed in terms of traffic that colors, with green representing conforming,
   yellow representing partially conforming and red representing non-
   conforming.  Often these multi-conformance level meters 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
   implemented using an appropriate configuration of the
   available capacity for the service level. By doing so, it
   compromises the other traffic stream. multiple two-
   parameter TB meters.

   A shaper that acts
   independently on the two streams can be used to limit the effect of
   the rogue stream. Note also that profile for a BA multi-stage TB meter with three levels of conformance
   might be metered against look as follows:

      Meter4:
      Type:                MultiTokenBucket
      Profile4:            output A
      Profile5:            output B
      NonConforming:       output C

      Profile4:
      Type:                SimpleTokenBucket
      AverageRate:         100 KBps
      BurstSize:           20 KB

      Profile5:
      Type:                SimpleTokenBucket
      AverageRate:         100 KBps
      BurstSize:           100 KB

5.2.5  Null Meter

   A null meter has only one
   profile whilst being shaped to output: always conforming, and no
   associated temporal profile.  Such a different profile further
   downstream meter is useful to define in the same device.

5.2.2.2 Formal Representation of a Shaper

   The following formal definition can be used
   event that the configuration or management interface does not have
   the flexibility to represent omit a shaper:

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

   Profile definitions a datapath segment.

6.  Action Elements

   Classifiers and meters are identical in format fan-out elements which are generally used
   to those described under determine the formal definition of a meter.

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

5.2.3 Droppers

Bernet, Smith, Blake    expires December, 1999                      16
   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 apply to represent a dropper:

   ActionElement03:
   Type:        Dropper

5.2.4 Monitoring

   One passive form packet.  The set of an
   possible actions include:

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

   The corresponding action to be taken is simply to account for elements are described in the fact that following
   paragraphs.

   Policing is a data packet was processed. This might be used later
   on in presenting statistics for customer usage-based  billing.
   Further discussion of instrumentation general term for monitoring is provided in
   section 0 although the topic process of accounting is not dealt with in
   detail here.

6. Traffic Conditioning Blocks (TCBs)

   The classifiers and preventing a traffic conditioning elements
   stream from seizing more than its share of resources from a Diffserv
   network.  Each of the first three actions described above
   can may be combined into used
   to police traffic.  Markers do so by re-marking non-conforming
   packets to a DSCP value that is entitled to fewer network resources.
   Shapers and droppers do so by limiting the rate at which a particular
   traffic conditioning blocks (TCBs). The TCB stream is submitted to the network.

6.1  Marker

   Markers are 1:1 elements which set the DSCP in an abstraction IP header (in
   the case of a functional block that unlabeled packets).  Markers may be used to facilitate act on unmarked packets
   (submitted with DSCP of zero) or may re-mark previously marked
   packets.  In particular, the definition model supports the application of traffic conditioning functionality.

   A general TCB consists
   marking based on a preceding classifier match.  The DSCP set in a
   packet will determine its subsequent treatment in downstream nodes
   of three stages:

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

   TCBs a network, and possible in subsequent processing stages within the
   router (depending on configuration).

   Markers are constructed normally parameterized by connecting elements corresponding a single parameter: the 6-bit
   DSCP to these
   stages be marked in any order. It the packet header.

      ActionElement1:
      Type:                Marker
      Mark:                010010

   In the case of a MPLS labeled packet, the marker is allowable to omit stages or parameterized
   by a 3-bit EXP value to
   concatenate multiple stages of be marked in the same type. TCB outputs may drive
   additional TCBs (on MPLS shim header.

6.2  Dropper

   Droppers simply discard packets. There are no parameters for
   droppers.  Because a dropper is a terminating point of the same interface or on an egress interface) or
   alternatively, datapath,
   it may be directed desirable to a PHB queue on an egress
   interface.

6.1 Example TCB forward the packet through a monitor first
   for instrumentation purposes.

   Droppers are not the only elements than can cause a packet to be
   discarded.  The following diagram illustrates other element is an example TCB:

Bernet, Smith, Blake    expires December, 1999                      17
                                        -------------> enqueueing element (see Sec.
   6.6).  However, since the enqueueing element's behavior is closely
   tied the state of one or more queues, we choose to Queue A
                               -------  |
                               |     |---
                            -->|     |
                            |  |     |---  -------
                            |  -------  |  |     |
                            |   meter   -->|     |-----> discard
                            |              |     |
                            |              -------
                            |              dropper
                            |
                            |
                            |           -------------> distinguish them
   as separate functional elements.

6.3  Shaper

   Shapers are used to Queue B
    submitted  -------      |  -------  |           ^ shape traffic   |  A  |-------  |     |---           |
           --->|  B  |-------->|     |              |
               |  C  |-------  |     |---  -------  |
               |  X  |----  |  -------  |  |     |  |
               -------   |  |   meter   -->|     |---
                 BA      |  |              |     |
              classifier |  |              -------
                         |  |              shaper
                         |  |
                         |  |
                         |  |           -------------> to Queue C
                         |  |  -------  |
                         |  |  |     |---
                         |  -->|     |
                         |     |     |---  -------
                         |     -------  |  |     |
                         |      meter   -->|     |---> to Queue D
                         |                 |     |
                         |                 -------
                         |                re-marker
                         |
                         ----------------------------> streams to Queue E

             Figure 4 - An Example Traffic Conditioning Block

   This sample TCB might a certain temporal
   profile.  For example, a shaper can be suitable for an ingress interface at used to smooth traffic
   arriving in bursts.  In [DSARCH] a
   customer/provider interface. A SLA shaper is presumed to have been
   negotiated between the customer and the provider described as a
   queueing element controlled by a meter which specifies the
   handling defines its temporal
   profile.  This model of a shaper differs substantially from typical
   shaper implementations.  Further, with the customer's traffic by the provider's network. The
   agreement might be inclusion 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 queueing
   elements 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
   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, model a separate shaping element becomes confusing.
   Therefore, the classification stage consists function of a single BA
   classifier. The BA classifier shaper is used embedded in a queue and is
   covered in Sec. 7.

6.4  Mirroring Element

   It is occasionally desirable to separate mirror data traffic based on
   the diffserv service level requested by the customer (as indicated
   by the DSCP in one or more
   additional interfaces for data collection purposes.  A mirroring
   element is a 1:N (fan-out) element.  However, each submitted packet's IP header). We illustrate
   three DSCP filter values: A, B and C. The 'X' in every packet
   follows each output path simultaneously.  A mirroring element is
   parameterized by the BA classifier
   indicates 'no match'.

   The metering stage number of outputs it supports.

6.5  Mux

   It is next. There occasionally necessary to multiplex traffic streams into a 1:1
   or 1:N action element or classifier.  A M:1 (fan-in) mux is a separate meter simple
   logical device for each set merging traffic streams.  It is parameterized by
   its number of packets corresponding incoming ports.

6.6  Enqueueing Element

   Queueing elements (discussed in Sec. 7) require an action element to DSCPs A, B
   execute the appropriate buffer management algorithm and C. Each meter uses store or
   discard a
   specific profile as specified in the SLA for packet.  This is performed by an enqueueing element, which
   is an M:1 (fan-in) element.  An enqueueing element executes the corresponding
   diffserv service level. The meters in this example indicate one of
   two conforming levels, conforming or non-conforming.

   Following
   buffer management algorithm appropriate for the metering stage queue it is feeding.
   This may include a deterministic discard behavior if the action stage. Packets submitted
   for DSCP A that are deemed non-conforming are discarded. Packets queue size
   exceeds a threshold, it may include a random discard behavior that are conforming are passed on to
   is a function of the average queue for size [AF-PHB], or it may include
   a more complex policy which is a function of the corresponding
   PHB.

   Packets submitted for DSCP B that are deemed non-conforming are
   delayed state of several
   queues in a shaper until they become conforming. Packets that are
   deemed conforming are allowed queue set (see Sec. 7).  The particular parameters to pass directly
   apply to the queue for PHB
   B.

   Note that in actual implementations, non-conforming packets will
   cause packets a packet may depend on the same traffic stream that particular input port the element
   receives it on; this allows packets which are conforming to be
   delayed in order classified into
   different colors to maintain per-stream packet ordering. However,
   this is an implementation detail follow different datapaths and need not be considered from processed
   appropriately at the
   abstract management perspective.

   Packets submitted enqueueing element.

   The configuration parameters for DSCP C an enqueueing element will depend on
   the details of the algorithm it is executing.  For an algorithm such
   as the one recommended in [AF-PHB], the parameters would include
   separate RED min_th, max_th, and deemed non-conforming are re-marked max_p parameters per-element input
   port.

   An enqueueing element must maintain octet/packet counters for a less privileged DSCP both
   the forwarded and are directed discarded packets received at each element input
   port.  Counters should be provided to the appropriate PHB
   queue. Packets that are deemed conforming are passed directly distinguish between losses due
   to the
   requested PHB queue.

6.2 Formal Representation normal operation of TCB

   The following the algorithm (e.g., random drop) and
   those due to resource exhaustion (e.g., tail drop) [DSMIB].

6.7  Monitor

   One passive action is a formal representation of to account for the interconnection of fact that a data packet was
   processed.  The statistics that result might be used later for
   customer billing, service verification, or network engineering
   purposes.  Monitors are 1:1 functional elements which increment an
   octet counter by L and a packet counter by 1 every time a L-byte
   sized packet passes through it.  Monitors can also be used to count
   packets on the components verge 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
   Meter1:
   Output A --> QueueA
   Output B --> ActionElement1 (dropper)

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

   ActionElement2:
   DefaultOutput --> QueueB

   Meter3:
   Output being dropped by a dropper.

6.8  Null Action

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

   ActionElement3:
   DefaultOutput --> QueueD

6.3 Example TCB to Support Multiple Customers null action has one input and one output.  The TCB described above can be installed element performs no
   action on the packet.  Such an ingress interface element is useful to
   implement a provider/customer agreement if define in the
   event that the configuration or management interface is
   dedicated to does not have
   the customer. However, if flexibility to omit an action element in a single interface datapath segment.

7.  Queues

7.1  Queue Sets and Scheduling

   Queues are used to store packets prior to transmission or prior to
   forwarding to the next functional element.  Packets are usually
   stored either because there is shared
   between multiple customers, then a resource constraint (e.g., available
   bandwidth) which prevents immediate forwarding, or because 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 queue
   is readily extended being used to support alter the case temporal properties of multiple
   customers per interface, as follows. First, we define a TCB for traffic stream
   (shaping).  Queues may be organized into queue sets, which are
   serviced using a common scheduling algorithm (although each
   customer queue may
   be individually parameterized).  Queue sets can be treated as
   functional elements and organized hierarchically in queue supersets,
   using an n-th order scheduling algorithm.  Such a queue set may be
   used to reflect the agreement with that customer. TCB1, defined
   above is implement the TCB for customer 1. We add definitions for TCB2 and entire range of PHBs on an egress interface,
   for
   TCB3 which reflect the agreements with customers 2 and 3
   respectively.

   Finally, we add instance.

   Possible queue scheduling algorithms fall into a fourth TCB, TCB4, which provides number of
   categories, including strict priority, weighted fair bandwidth
   sharing (e.g., WFQ, WRR, etc.), rate-limited strict priority, etc.
   Scheduling algorithms can be further distinguished by whether they
   are work conserving or non-work conserving.  A work conserving
   algorithm will always transmit an available packet at every
   transmission opportunity, while a front end non-work conserving algorithm will
   not.  Non-work conserving schedulers can be used to
   separate the shape traffic from the three different customers. This can
   streams by delaying packets that would be
   illustrated as:

       submitted  +-----+ deemed non-conforming by
   some traffic   |  A  |--------> TCB1
              --->|  B  |--------> TCB2
                  |  C  |--------> TCB3
                  |  X  |--------> ActionElement4 (dropper)
                  +-----+
                   TCB4

             Figure 5 - An Example Multi-Cusomer Front End TCB

   A formal representation profile.  The packet is delayed until such time that it
   would conform to a meter using the same profile.

   [DSARCH] defines PHBs without specifying required queueing
   algorithms.  However, PHBs such as EF [EF-PHB] and AF [AF-PHB] have
   configuration parameters which strongly suggest the sort of this multi-customer TCB might be:

   TCB1:

Bernet, Smith, Blake    expires December, 1999                      20
   (as defined above)

   TCB2:
   (similar queue
   scheduling algorithm needed to TCB1, perhaps with different numeric parameters)

   TCB3:
   (similar implement them.  We have selected a
   minimal set of queue parameters to TCB1, perhaps enable realization of these per-
   hop behaviors.  These include a minimum service rate and a strict
   service priority along with different numeric parameters)

   TCB4:

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

   Where Classifier2 an optional maximum service rate profile
   (depending on whether the queue is defined meant to be non-work conserving).
   The minimum service rate allows throughput guarantees for each queue
   as follows:

   Classifier2:
   Filter1:     output A
   Filter2:     output B
   Filter3:     output C
   No Match:    output X required by EF and AF without specifying 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 details 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 how excess
   bandwidth between these queues is shared (additional parameters to Filter1 but with customer 3's source MAC address as
   SrcValue)

   In
   control this example, TCB4 separates traffic submitted from different
   customers based behavior should be made available, but are dependent on
   the source MAC address in submitted packets.
   Those packets with recognized source MAC addresses are passed particular scheduling algorithm implemented).  The strict service
   priority is useful for implementing EF on some links (assuming that
   the aggregate EF rate has been appropriately bounded to avoid
   starvation).  Setting the
   TCB implementing service priority of each queue in a queue
   set to the agreement with same value enables the corresponding customer.
   Those packets with unrecognized source MAC addresses are passed scheduler to satisfy the minimum
   service rate for each queue.  Queue sets can be serviced like
   individual queues in a
   dropper.

   TCB4 has a classification stage and an action element stage (it is queue superset using the same scheduling
   parameters.

   It should be noted that the queues in this model are logical
   abstractions used only for unrecognized traffic) i.e. all actions to configure PHB-related parameters.  They are the default
   which is not
   expected to pass through unchanged. Its outputs drive either the
   dropper action element or additional TCBs.

Bernet, Smith, Blake    expires December, 1999                      21

6.4 TCBs Supporting Microflow-based Services

   The TCB illustrated above describes a TC configuration that might be
   suitable for enforcing a SLA at map one-to-one with physical queues in a router's ingress. It assumes that specific router
   implementation.  An implementor should map the customer marks its own traffic for configurable
   parameters of the physical queues to these queue parameters as
   appropriate service
   level. It then limits the rate of aggregate traffic submitted at
   each service level, thereby protecting to achieve equivalent behaviors.

   Other queue parameters such as maximum capacity are assumed to be
   mapped to the resources of buffer management algorithm used by the diffserv
   network. It does not mark enqueueing
   element feeding the customer's packets, nor does it
   provide any isolation between queue.

   A queue set might be represented using the customer's individual microflows.

   Next we present a TC configuration that offers additional
   functionality following parameters:

      QueueSet1:
      Type:        QueueSet
      MaxProfile:  WorkConserving
      MinGuarRate: 20 MBps
      Interface:   ifIndex
      QueueA:
      Type:        Queue
      QueueSet:    QueueSet1
      MaxProfile:  Profile1
      MinGuarRate: 2 MBps
      Priority:    3

      QueueB:
      Type:        Queue
      QueueSet:    QueueSet1
      MaxProfile:  WorkConserving
      MinGuarRate: 8 MBps
      Priority:    3

7.2  Shaping

   Shapers are often used to the customer. It recognizes individual customer
   microflows and marks each one independently. It also isolates the
   customer's individual microflows from each other pre-condition traffic such that packets
   are deemed conforming by subsequent meters, e.g., in order downstream
   Diffserv nodes.  Shapers may also be used to prevent
   a single microflow isolate certain traffic
   streams from seizing an unfair share the effects of other traffic streams of the resources
   available same BA.

   A shaper action element is implemented in this model by using a non-
   work conserving queue.  Shapers operate by delaying packets that
   would be deemed non-conforming by a meter configured to the customer at a certain shaper's
   maximum service level. This rate profile.  The packet is
   illustrated delayed until such
   time that it would become conforming.

   Profile definitions are identical in Figure 6 below:

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

       Figure 6 - An Example format to those described for
   meters.  The use of a Marking meter algorithm to control shaping is further
   discussed in Appendix A.  Average, EWMA, and Traffic Isolation TCB

   Traffic TB profiles are all
   feasible for shaping.  Because a shaper is first directed to an MF classifier which classifies
   traffic based on miscellaneous classification criteria, to implemented as a
   granularity sufficient to identify  individual customer microflows.
   Each microflow queue it
   can then be marked for also utilize a specific DSCP (in this
   particular example we assume that one variety of two different DSCPs is
   marked). The metering stage limits buffer management algorithms
   (implemented in a enqueueing element).

   A shaping queue might be represented using the contribution of each following parameters:

      QueueA:
      Type:        Queue
      QueueSet:    QueueSet1
      MaxProfile:  Profile1
      MinGuarRate: 2 MBps
      Priority:    3

      Profile1:
      Type:                SimpleTokenBucket
      AverageRate:         3 MBps
      BurstSize:           8 KB

8.  Traffic Conditioning Blocks (TCBs)

   The classifiers, meters, action elements, and queueing elements
   described above can be combined into traffic conditioning blocks
   (TCBs).  The TCB is an abstraction of the
   customer's microflows a functional element that may
   be used to facilitate the service level for which it was marked.
   Packets exceeding the allowable limit for definition of specific traffic conditioning
   functionality.

   One of the microflow are dropped.

   The TCB simplest possible TCBs would be formally specified as follows:

Bernet, Smith, Blake    expires December, 1999                      22

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 consist of the following
   stages:

   1.  Classifier stage
   2.  Enqueueing stage
   3.  Queueing stage

   Note that a classifier is a 1:N element, while an enqueueing stage is
   a N:1 element declarations are not shown here.

   Traffic and a queue is either dropped by TCB1 or emerges marked for one of two
   DSCPs. This a 1:1 element.  If the classifier split
   traffic is across multiple enqueueing elements 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
   Meter11:
   Output A --> PHBQueueB
   Output B --> ActionElement11 (dropper)

7. Queuing Components

   Queuing components are the final conceptual components of the model queueing stage
   may consist of a diffserv router before hierarchy of queue sets, all resulting in a 1:1
   abstract element.

   A more general TCB might consists of the following four stages:

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

   where each stage may consist of a set of parallel datapaths
   consisting of pipelined elements.

   TCBs are constructed by connecting elements corresponding to these
   stages in any sensible order.  It is possible to omit stages, to
   include null elements, or to concatenate multiple stages of the same
   type.  TCB outputs may drive additional TCBs (on either the ingress
   or egress interfaces).   Classifiers and meters are fan-out elements,
   muxes and enqueueing elements are fan-in elements.

8.1  An Example TCB

   The following diagram illustrates an example TCB:

                                       +------------> to Queue A
                              +-----+  |              (not shown)
                              |     |--+
                           +->|     |
                           |  |     |--+  +-----+    +-----+
                           |  +-----+  |  |     |    |     |
                           |   meter   +->|     |--->|     |
                           |              |     |    |     |
                           |              +-----+    +-----+
                           |              monitor    dropper
                           |
                           |
                           |
     submitted +-----+     |  +-----+     +-----+
     traffic   |  A  |-----+  |     |     |     |
           --->|  B  |------->|     |---->|     |---> to Queue B
               |  C  |-----+  |     |     |     |     (not shown)
               |  X  |--+  |  +-----+     +-----+
               +-----+  |  |   marker     shaper
                 BA     |  |              queue
              classifier|  |
                        |  |
                        |  |
                        |  |
                        |  |
                        |  |  +-----+                +-----+
                        |  |  |     |--------------->|     |  to Queue C
                        |  +->|     |                |     |->
                        |     |     |--+  +-----+ +->|     | (not shown)
                        |     +-----+  |  |     | |  +-----+
                        |      meter   +->|     |-+    mux
                        |                 |     |
                        |                 +-----+
                        |                 marker
                        |
                        +---------------------------> to Queue D
                                                      (not shown)
      Figure 5:  An Example Traffic Conditioning Block

   This sample TCB might be suitable for an ingress interface at a
   customer/provider boundary.  A SLS 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      Discard
      001100       PHB2      Profile2      Wait in shaper queue
      001101       PHB3      Profile3      Re-mark to DSCP 001000
   It is implicit in this agreement that conforming packets are given
   the PHB originally indicated by the packets' DSCP field.  It
   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
   is the default wildcard filter that matches every packet.

   A metering stage is next in the upper and lower branches.  There is a
   separate meter for each set of packets corresponding to DSCPs A and
   C.  Each meter uses a specific profile as specified in the TCS for
   the corresponding Diffserv service level.  The meters in this
   example indicate one of two conforming levels, conforming or
   non-conforming.  The middle branch has a marker which re-marks all
   packets received with DSCP B.

   Following the metering stage is the action stage in the upper and
   lower branches.  Packets submitted for DSCP A that are deemed non-
   conforming and are counted and discarded.  Packets that are
   conforming are passed on to Queue A.  Packets submitted for DSCP C
   that are deemed non-conforming are re-marked, and then conforming and
   non-conforming packets are muxed together before being forwarded to
   Queue C.  Packets submitted for DSCP B are shaped to Profile2 before
   being forwarded to Queue B.

   The interconnections of the TCB elements illustrated in Fig. 5 can be
   represented as follows:

      TCB1:

      Classifier1:
      Output A --> Meter1
      Output B --> Marker1
      Output C --> Meter2
      Output X --> QueueD

      Meter1:
      Output A --> QueueA
      Output B --> Monitor1

      Monitor1:
      Output A --> Dropper1

      Marker1:
      Output A --> Shaper1
      Shaper1:
      Output A --> Queue B

      Meter2:
      Output A --> Mux1
      Output B --> Marker2

      Marker2:
      Output A --> Mux1

      Mux1:
      Output A --> Queue C

8.2  An Example TCB to Support Multiple Customers

   The TCB described above can be installed on an ingress interface to
   implement a provider/customer TCS 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 only BA classifiers.

   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 TCS 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 classifier which provides a front end to separate
   the traffic from the three different customers.  This forms a new
   TCB which incorporates TCB1, TCB2, and TCB3, and can be illustrated
   as follows:

      submitted +-----+
      traffic   |  A  |--------> TCB1
            --->|  B  |--------> TCB2
                |  C  |--------> TCB3
                |  X  |--------> Dropper4
                +-----+
                Classifier4

      Figure 6: An Example of a Multi-Customer TCB

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

      TCB1:
      (as defined above)

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

      TCB4:
      (the total TCB)

      Classifier4:
      Output A --> TCB1
      Output B --> TCB2
      Output C --> TCB3
      Output X --> Dropper4

   Where Classifier2 is defined as follows:

      Classifier4:
      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 follows:

      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, Classifier4 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 TCS 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, which
   consists of either a dropper or another TCB.

8.3 TCBs Supporting Microflow-based Services

   The TCB illustrated above describes a configuration that might be
   suitable for enforcing a SLS 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 provide any isolation between the customer's
   individual microflows (other than from separated queueing).

   Next we present a TCB 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 7 below:

                     +-----+   +-----+
                     |     |   |     |---------------+
                  +->|     |-->|     |     +-----+   |
        +-----+   |  |     |   |     |---->|     |   |
        |     |----  +-----+   +-----+     +-----+   |
      ->|     |----  marker     meter      dropper   |   +-----+   to
        |     |-+ |  +-----+   +-----+               +-->|     |
        +-----+ | |  |     |   |     |------------------>|     |--->
          MF    | +->|     |-->|     |     +-----+   +-->|     |
        class.  |    |     |   |     |---->|     |   |   +-----+  TCB2
                |    +-----+   +-----+     +-----+   |    mux
                |    marker     meter      dropper   |
                |    +-----+   +-----+               |
                |    |     |   |     |---------------+
                |--->|     |-->|     |     +-----+
                |    |     |   |     |---->|     |
                |    +-----+   +-----+     +-----+
                |    marker     meter      dropper
                |       .         .     .
                V       V         V     V

      Figure 7: An Example of a Marking and Traffic Isolation TCB

   Traffic is first directed to a 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 could be formally specified as follows:

      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 8: Additional Example TCB

   TCB2 would be formally specified as follows:

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

      Meter11:
      Output A --> PHBQueueB
      Output B --> Dropper11

9.  Open Issues

  o  There is a difference in interpretation of token bucket behavior
     between this document (Appendix A) and [DSMIB].  Specifically,
     [DSMIB] allows a packet to conform if any smaller packet would
     conform.

  o  The meter in [SRTCM] cannot be precisely modeled using two
     two-parameter token buckets because its two buckets do not
     accumulate credits independently.  We intended to demonstrate how
     the [TRTCM] meter could be implemented but ran out of time.

  o  Are the queue parameters (scheduling and buffer management)
     parameters defined sufficient?

  o  Does Queue and Queue Set really belong in the model (and the MIB
     and PIB?), or should the model stick to the abstract PHB
     representation and leave the implementation details to the MIB and
     PIB?

  o  Should a classifier be part of a TCB?  We argue yes.  This allows a
     TCB to be a one input/one output black box element.

  o  Is the description of a shaper sufficient?  Is it overbroad?

10. Security Considerations

   Security vulnerabilities of Diffserv network operation are discussed
   in [DSARCH].  This document describes an abstract functional model of
   Diffserv router elements.  Certain denial-of-service attacks such as
   those resulting from resource starvation may be mitigated by
   appropriate configuration of these router elements; for example, by
   rate limiting certain traffic streams or by authenticating traffic
   marked for higher quality-of-service.

11.  Acknowledgments

   Concepts, terminology, and text have been borrowed liberally from
   [DSMIB] and [PIB].  We wish to thank the authors: Fred Baker,
   Michael Fine, Keith McCloghrie, John Seligson, Kwok Chan, and
   Scott Hahn, for their permission.

   This document has benefitted from the comments and suggestions of
   several participants of the Diffserv working group.

12. References

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

   [DSTERMS]  D. Grossman, "New Terminology for Diffserv", Internet
              Draft <draft-ietf-diffserv-new-terms-00.txt>, October
              1999.

   [E2E]      Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang,
              M. Speer, K. Nichols, R. Braden, B. Davie, J. Wroclawski,
              and E. Felstaine, "Integrated Services Operation over
              Diffserv Networks", Internet Draft
              <draft-ietf-issll-diffserv-rsvp-02.txt>, September 1999.

   [DSFIELD]  K. Nichols, S. Blake, F. Baker, and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474, December
              1998.

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

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

   [DSMIB]    F. Baker, "Differentiated Services MIB", Internet Draft
              <draft-ietf-diffserv-mib-00.txt>, June 1999.

   [SRTCM]    J. Heinanen, and R. Guerin, "A Single Rate Three Color
              Marker", RFC 2697, September 1999.

   [PIB]      M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn,
              and A. Smith, "Quality of Service Policy Information
              Base", Internet Draft <draft-mfine-cops-pib-01.txt>,
              June 1999.

   [TRTCM]    J. Heinanen, R. Guerin, "A Two Rate Three Color Marker",
              RFC 2698, September 1999.

   [GTC]      L. Lin, J. Lo, and F. Ou, "A Generic Traffic Conditioner",
              Internet Draft <draft-lin-diffserv-gtc-01.txt>, August
              1999.

   [MPLSDS]   J. Heinanen, "Differentiated Services in MPLS Networks",
              Internet Draft <draft-heinanen-diffserv-mpls-00.txt>,
              June 1999.

Appendix A.  Simple Token Bucket Definition

  [DSMIB] presents a device. The queuing
   behaviours implemented fairly detailed exposition on an egress interface are modeled as a set the operation of inter-dependent queues that are serviced by a queuing algorithm
  two-parameter token buckets for metering.  However, the behavior
  described does not appear to be consistent with certain parameters the behavior defined
  in [SRTCM] and profiles. In particular, [TRTCM].  Specifically, under the scheduling
   parameters may be definition in
  [DSMIB], a packet is assumed to conform to the meter if any of its
  bytes would have been accepted, while in [SRTCM] and [TRTCM], a packet
  is assumed to conform only if sufficient tokens are available for
  every byte in the Profile types packet.  Further, a packet has no effect on the
  token occupancy if it does not conform (no tokens are decremented).

  The behavior defined in [SRTCM] and [TRTCM] is not mandatory 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
  compliance, but we give here a mathematical definition of parameters two-
  parameter token bucket operation which is a strawman for comment>

8. Monitoring

   Generally, it should be possible to retrieve the TCTs consistent with these
  documents, and similar
   tabular representations of the different diffserv router components.
   It should which can be possible to monitor the count of packets submitted used to
   each TC element define a shaping profile.

  Define a token bucket with bucket size BS, token accumulation rate
  R, and instantaneous token occupancy T(t).  Assume that T(0) = BS.

  Then after an arbitrary interval with no packet arrivals, T(t) will
  not change since the disposition bucket is already full of the tokens.  Assume a
  packet (which of size B bytes at time t'.  The bucket capacity T(t'-) = BS
  still.  Then, as long as B <= BS, the
   element outputs it was directed to).

Bernet, Smith, Blake    expires December, 1999                      24
   In packet conforms to the case meter,
  and

     T(t') = BS - B.

  Assume an interval v = t - t' elapses before the next packet, of
  size C <= BS, arrives.  T(t-) is given by the installation in following equation:

    T(t-) = max { BS, T(t') + v*R }

  (the packet has accumulated v*R tokens over the interval, up to a router
  maximum of BS tokens).

  If T(t-) - C >= 0, the packet filters that
   conflict, it must conforms and T(t) = T(t-) - C.
  Otherwise, the packet does not conform and T(t) = T(t-).

  This function can be possible used to determine the relative precedence define a shaping profile.  If a packet of the filters
  size C arrives at time t, it will be eligible for transmission at time
  te given as implemented by follows (we still assume C <= BS):

     te = max { t, t" }

  where

     t" = (C - T(t') + t'*R)/R.

  T(t") = C, the router.

9. Initial State

   (TBD)

   <should we discuss here time when C credits have accumulated in 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. bucket,
  and D. Black,
   "Definition of when the Differentiated Services Field (DS Field) in packet would conform if 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
   [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 token bucket were a meter.
  te != t" only if t > t".

Authors' 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  +1 919 468 8466 x232
   E-mail: slblake@torrentnet.com

Bernet, Smith, Blake    expires December, 1999                      26