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

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 3670

 Policy Framework Working Group                                  B Moore
 INTERNET-DRAFT                                          IBM Corporation
 Category: Standards Track                                     D. Durham
                                                                   Intel
                                                            J. Strassner
                                                        INTELLIDEN, Inc.
                                                           A. Westerinen
                                                           Cisco Systems
                                                                W. Weiss
                                                                Ellacoya
                                                                May 2002
 
 
 
     Information Model for Describing Network Device QoS Datapath
                              Mechanisms
 
            <draft-ietf-policy-qos-device-info-model-08.txt>
                    Thursday, May 30, 2002, 2:30 PM
 
 Status of this Memo
 
   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC2026.
 
   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.
 
   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-
   Drafts as reference material or to cite them other than as "work
   in progress."
 
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
 
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html
 
 Copyright Notice
 
   Copyright (C) The Internet Society (2002).  All Rights Reserved.
 
 
 
 
 
 
 
 
 
 
 
 Moore, et al.          Expires: May 2002 + 6 months            [Page 1]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
 Abstract
 
   The purpose of this draft is to define an information model to
   describe the quality of service (QoS) mechanisms inherent in
   different network devices, including hosts.  Broadly speaking,
   these mechanisms describe the properties common to selecting and
   conditioning traffic through the forwarding path (datapath) of a
   network device.  This selection and conditioning of traffic in
   the datapath spans both major QoS architectures: Differentiated
   Services (see [R2475]) and Integrated Services (see [R1633]).
 
   This draft is intended to be used with the QoS Policy Information
   Model [QPIM] to model how policies can be defined to manage and
   configure the QoS mechanisms (i.e., the classification, marking,
   metering, dropping, queuing, and scheduling functionality) of
   devices.  Together, these two drafts describe how to write QoS
   policy rules to configure and manage the QoS mechanisms present
   in the datapaths of devices.
 
   This draft, as well as [QPIM], are information models.  That is,
   they represent information independent of a binding to a specific
   type of repository.  A separate draft could be written to provide
   a mapping of the data contained in this document to a form
   suitable for implementation in a directory that uses (L)DAP as
   its access protocol.  Similarly, a draft could be written to
   provide a mapping of the data in [QPIM] to a directory.
   Together, these four drafts (information models and directory
   schema mappings) would then describe how to write QoS policy
   rules that can be used to store information in directories to
   configure device QoS mechanisms.
 
 Definition of Key Word Usage
 
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   RFC 2119 [R2119].
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                 [Page 2]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
 Table of Contents
 
   1. Introduction......................................................5
      1.1. Policy Management Conceptual Model...........................6
      1.2. Purpose and Relation to Other Policy Work....................7
      1.3. Typical Examples of Policy Usage.............................7
   2. Approach..........................................................8
      2.1. Common Needs Of DiffServ and IntServ.........................8
      2.2. Specific Needs Of DiffServ...................................9
      2.3. Specific Needs Of IntServ...................................10
   3. Methodology......................................................10
      3.1. Level of Abstraction for Expressing QoS Policies............10
      3.2. Specifying Policy Parameters................................12
      3.3. Specifying Policy Services..................................12
      3.4. Level of Abstraction for Defining QoS Attributes and
      Classes..........................................................13
      3.5. Characterization of QoS Properties..........................14
      3.6. QoS Information Model Derivation............................15
      3.7. Attribute Representation....................................16
      3.8. Mental Model................................................17
      3.8.1. The QoSService Class......................................17
      3.8.2. The ConditioningService Class.............................19
      3.8.3. Preserving QoS Information from Ingress to Egress.........20
      3.9. Classifiers, FilterLists, and Filter Entries................21
      3.10. Modeling of Droppers.......................................23
      3.10.1. Configuring Head and Tail Droppers.......................23
      3.10.2. Configuring RED Droppers.................................24
      3.11. Modeling of Queues and Schedulers..........................25
      3.11.1. Simple Hierarchical Scheduler............................25
      3.11.2. Complex Hierarchical Scheduler...........................27
      3.11.3. Excess Capacity Scheduler................................28
      3.11.4. Hierarchical CBQ Scheduler...............................30
   4. The Class Hierarchy..............................................32
      4.1. Associations and Aggregations...............................33
      4.2. The Structure of the Class Hierarchies......................33
      4.3. Class Definitions...........................................38
      4.3.1. The Abstract Class ManagedElement.........................38
      4.3.2. The Abstract Class ManagedSystemElement...................38
      4.3.3. The Abstract Class LogicalElement.........................39
      4.3.4. The Abstract Class Service................................39
      4.3.5. The Class ConditioningService.............................39
      4.3.6. The Class ClassifierService...............................40
      4.3.7. The Class ClassifierElement...............................41
      4.3.8. The Class MeterService....................................42
      4.3.9. The Class AverageRateMeterService.........................43
      4.3.10. The Class EWMAMeterService...............................44
      4.3.11. The Class TokenBucketMeterService........................45
      4.3.12. The Class MarkerService..................................46
      4.3.13. The Class PreambleMarkerService..........................47
      4.3.14. The Class ToSMarkerService...............................47
      4.3.15. The Class DSCPMarkerService..............................48
      4.3.16. The Class 8021QMarkerService.............................49
 
 
 Moore, et al.     Expires: May 2002 + 6 months                 [Page 3]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
      4.3.17. The Class DropperService.................................49
      4.3.18. The Class HeadTailDropperService.........................51
      4.3.19. The Class REDDropperService..............................51
      4.3.20. The Class QueuingService.................................53
      4.3.21. The Class PacketSchedulingService........................54
      4.3.22. The Class NonWorkConservingSchedulingService.............55
      4.3.23. The Class QoSService.....................................55
      4.3.24. The Class DiffServService................................56
      4.3.25. The Class AFService......................................57
      4.3.26. The Class FlowService....................................58
      4.3.27. The Class DropThresholdCalculationService................59
      4.3.28. The Abstract Class FilterEntryBase.......................59
      4.3.29. The Class IPHeaderFilter.................................60
      4.3.30. The Class 8021Filter.....................................60
      4.3.31. The Class PreambleFilter.................................60
      4.3.32. The Class FilterList.....................................61
      4.3.33. The Abstract Class ServiceAccessPoint....................61
      4.3.34. The Class ProtocolEndpoint...............................61
      4.3.35. The Abstract Class Collection............................62
      4.3.36. The Abstract Class CollectionOfMSEs......................62
      4.3.37. The Class BufferPool.....................................62
      4.3.38. The Abstract Class SchedulingElement.....................63
      4.3.39. The Class AllocationSchedulingElement....................64
      4.3.40. The Class WRRSchedulingElement...........................65
      4.3.41. The Class PrioritySchedulingElement......................66
      4.3.42. The Class BoundedPrioritySchedulingElement...............67
      4.4. Association Definitions.....................................68
      4.4.1. The Abstract Association Dependency.......................68
      4.4.2. The Association ServiceSAPDependency......................68
      4.4.3. The Association IngressConditioningServiceOnEndpoint......68
      4.4.4. The Association EgressConditioningServiceOnEndpoint.......69
      4.4.5. The Association HeadTailDropQueueBinding..................69
      4.4.6. The Association CalculationBasedOnQueue...................70
      4.4.7. The Association ProvidesServiceToElement..................71
      4.4.8. The Association ServiceServiceDependency..................71
      4.4.9. The Association CalculationServiceForDropper..............71
      4.4.10. The Association QueueAllocation..........................72
      4.4.11. The Association ClassifierElementUsesFilterList..........73
      4.4.12. The Association AFRelatedServices........................74
      4.4.13. The Association NextService..............................74
      4.4.14. The Association NextServiceAfterClassifierElement........75
      4.4.15. The Association NextScheduler............................76
      4.4.16. The Association FailNextScheduler........................77
      4.4.17. The Association NextServiceAfterMeter....................78
      4.4.18. The Association QueueToSchedule..........................79
      4.4.19. The Association SchedulingServiceToSchedule..............80
      4.4.20. The Aggregation MemberOfCollection.......................80
      4.4.21. The Aggregation CollectedBufferPool......................80
      4.4.22. The Abstract Aggregation Component.......................81
      4.4.23. The Aggregation ServiceComponent.........................81
      4.4.24. The Aggregation QoSSubService............................81
      4.4.25. The Aggregation QoSConditioningSubService................82
 
 
 Moore, et al.     Expires: May 2002 + 6 months                 [Page 4]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
      4.4.26. The Aggregation ClassifierElementInClassifierService.....83
      4.4.27. The Aggregation EntriesInFilterList......................84
      4.4.28. The Aggregation ElementInSchedulingService...............85
   5. Intellectual Property............................................85
   6. Acknowledgements.................................................85
   7. Security Considerations..........................................86
   8. References.......................................................86
   9. Authors' Addresses...............................................87
   10. Full Copyright Statement........................................88
   11. Appendix A:  Naming Instances in a Native CIM Implementation....90
      11.1. Naming Instances of the Classes Derived from Service.......90
      11.2. Naming Instances of Subclasses of FilterEntryBase..........90
      11.3. Naming Instances of ProtocolEndpoint.......................90
      11.4. Naming Instances of BufferPool.............................90
      11.4.1. The Property CollectionID................................91
      11.4.2. The Property CreationClassName...........................91
      11.5. Naming Instances of SchedulingElement......................91
 
 1. Introduction
 
   The purpose of this draft is to define an information model to
   describe the quality of service (QoS) mechanisms inherent in
   different network devices, including hosts.  Broadly speaking,
   these mechanisms describe the attributes common to selecting and
   conditioning traffic through the forwarding path (datapath) of a
   network device.  This selection and conditioning of traffic in
   the datapath spans both major QoS architectures: Differentiated
   Services (see [R2475]) and Integrated Services (see [R1633]).
 
   This draft is intended to be used with the QoS Policy Information
   Model [QPIM] to model how policies can be defined to manage and
   configure the QoS mechanisms (i.e., the classification, marking,
   metering, dropping, queuing, and scheduling functionality) of
   devices.  Together, these two drafts describe how to write QoS
   policy rules to configure and manage the QoS mechanisms present
   in the datapaths of devices.
 
   This draft, as well as [QPIM], are information models.  That is,
   they represent information independent of a binding to a specific
   type of repository.  A separate draft could be written to provide
   a mapping of the data contained in this document to a form
   suitable for implementation in a directory that uses (L)DAP as
   its access protocol.  Similarly, a draft could be written to
   provide a mapping of the data in [QPIM] to a directory.
   Together, these four drafts (information models and directory
   schema mappings) would then describe how to write QoS policy
   rules that can be used to store information in directories to
   configure device QoS mechanisms.
 
   The approach taken in this draft defines a common set of classes
   that can be used to model QoS in a device datapath.  Vendors can
   then map these classes, either directly or using an intervening
 
 
 Moore, et al.     Expires: May 2002 + 6 months                 [Page 5]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   format like a COP-PR PIB, to their own device-specific
   implementations.  Note that the admission control element of
   Integrated Services is not included in the scope of this model.
 
   The design of the class, association, and aggregation hierarchies
   described in this draft is influenced by the DMTF Network QoS
   submodel [CIM].  These hierarchies are not derived from the
   Policy Core Information Model [PCIM].  This is because the
   modeling of the QoS mechanisms of a device is separate and
   distinct from the modeling of policies that manage those
   mechanisms.  Hence, there is a need to separate QoS mechanisms
   (this draft) from their control (specified using the generic
   policy draft [PCIM] augmented by the QoS Policy draft [QPIM]).
 
   While it is not a policy model per se, this draft does have a
   dependency on the Policy Core Information Model Extensions draft
   [PCIME].  The device-level packet filtering, through which a
   Classifier splits a traffic stream into multiple streams, is
   based on the FilterEntryBase and FilterList classes defined in
   [PCIME].
 
 1.1. Policy Management Conceptual Model
 
   The Policy Core Information Model [PCIM] describes a general
   methodology for constructing policy rules.  PCIM Extensions
   [PCIME] updates and extends the original PCIM.  A policy rule
   aggregates a set of policy conditions and an ordered set of
   policy actions.  The semantics of a policy rule are such that if
   the set of conditions evaluates to TRUE, then the set of actions
   are executed.
 
   Policy conditions and actions have two principal components:
   operands and operators.  Operands can be constants or variables.
   To specify a policy, it is necessary to specify:
 
     o the operands to be examined (also known as state variables);
 
     o the operands to be changed (also known as configuration
        variables);
 
     o the relationships between these two sets of operands.
 
   Operands can be specified at a high-level, such as Joe (a user)
   or Gold (a service).  Operands can also be specified at a much
   finer level of detail, one that is much closer to the operation
   of the device.  Examples of the latter include an IP Address or a
   queue's bandwidth allocation.  Implicit in the use of operands is
   the binding of legal values or ranges of values to an operand.
   For example, the value of an IP address cannot be an integer.
   The concepts of operands and their ranges are defined in [PCIME].
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                 [Page 6]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   The second component of policy conditions and actions is a set of
   operators.  Operators can express both relationships (greater
   than, member of a set, Boolean OR, etc.) and assignments.
   Together, operators and operands can express a variety of
   conditions and actions, such as:
 
         If Bob is an Engineer...
         If the source IP address is in the Marketing Subnet...
         Set Joe's IP address to 2.3.4.5
         Limit the bandwidth of application x to 10 Mb
 
   We recognize that the definition of operator semantics is
   critical to the definition of policies.  However, the definition
   of these operators is beyond the scope of this document.  Rather,
   this draft (with [QPIM]) takes the first steps in identifying and
   standardizing a set of properties (operands) for use in defining
   policies for Differentiated and Integrated Services.
 
 1.2. Purpose and Relation to Other Policy Work
 
   This model establishes a canonical model of the QoS mechanisms of
   a network device (e.g., a router, switch, or host) that is
   independent of any specific type of network device.  This enables
   traffic conditioning to be described using a common set of
   abstractions, modeled as a set of services and sub-services.
 
   When the concepts of this draft are used in conjunction with the
   concepts of [QPIM], one is able to define policies that bind the
   services in a network to the needs of applications using that
   network.  In other words, the business requirements of an
   organization can be reflected in one set of policies, and those
   policies can be translated to a lower-level set of policies that
   control and manage the configuration and operation of network
   devices.
 
 1.3. Typical Examples of Policy Usage
 
   Policies could be implemented as low-level rules using the
   information model described in this specification.  For example,
   in a low-level policy, a condition could be represented as an
   evaluation of a specific attribute from this model.  Therefore, a
   condition such as "If filter = HTTP" would be interpreted as a
   test determining whether any HTTP filters have been defined for
   the device.  A high-level policy, such as "If protocol = HTTP,
   then mark with DSCP 24," would be expressed as a series of
   actions in a low-level policy using the classes and attributes
   described below:
 
   1.  Create HTTP filter
   2.  Create DSCP marker with the value of 24
   3.  Bind the HTTP filter to the DSCP marker
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                 [Page 7]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   Note that unlike "mark with DSCP 24," these low-level actions are
   not performed on a packet as it passes through the device.
   Rather, they are configuration actions performed on the device
   itself, to make it ready to perform the correct action(s) on the
   correct packet(s).  The act of moving from a high-level policy
   rule to the correct set of low-level device configuration actions
   is an example of what [POLTERM] characterizes as "policy
   translation" or "policy conversion".
 
 
 2. Approach
 
   QoS activities in the IETF have mainly focused in two areas,
   Integrated Services (IntServ) and Differentiated Services
   (DiffServ) (see [POLTERM], [R1633] and [R2475]).  This draft
   focuses on the specification of QoS properties and classes for
   modeling the datapath where packet traffic is conditioned.
   However, the framework defined by the classes in this document
   has been designed with the needs of the admission control portion
   of IntServ in mind as well.
 
 2.1. Common Needs Of DiffServ and IntServ
 
   First, let us consider IntServ.  IntServ has two principal
   components.  One component is embedded in the datapath of the
   networking device.  Its functions include the classification and
   policing of individual flows, and scheduling admitted packets for
   the outbound link.  The other component of IntServ is admission
   control, which focuses on the management of the signaling
   protocol (e.g., the PATH and RESV messages of RSVP).  This
   component processes reservation requests, manages bandwidth,
   outsources decision making to policy servers, and interacts with
   the Routing Table manager.
 
   We will consider RSVP when defining the structure of this
   information model.  As this draft focuses on the datapath,
   elements of RSVP applicable to the datapath will be considered in
   the structure of the classes.  The complete IntServ device model
   will, as we have indicated earlier, be addressed in a subsequent
   document.
 
   This draft models a small subset of the QoS policy problem, in
   hopes of constructing a methodology that can be adapted for other
   aspects of QoS in particular, and of policy construction in
   general.  The focus in this draft is on QoS for devices that
   implement traffic conditioning in the datapath.
 
   DiffServ operates exclusively in the datapath.  It has all of the
   same components of the IntServ datapath, with two major
   differences.  First, DiffServ classifies packets based solely on
   their DSCP field, whereas IntServ examines a subset of a standard
   flow's addressing 5-tuple.  The exception to this rule occurs in
 
 
 Moore, et al.     Expires: May 2002 + 6 months                 [Page 8]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   a router or host at the boundary of a DiffServ domain.  A device
   in this position may examine a packet's DSCP, its addressing 5-
   tuple, other fields in the packet, or even information wholly
   outside the packet, in determining the DSCP value with which to
   mark the packet prior to its transfer into the DiffServ domain.
   However, routers in the interior of a DiffServ domain will only
   need to classify based on the DSCP field.
 
   The second difference between IntServ and DiffServ is that the
   signaling protocol used in IntServ (e.g., RSVP) affects the
   configuration of the datapath in a more dynamic fashion.  This is
   because each newly admitted RSVP reservation requires a
   reconfiguration of the datapath.  In contrast, DiffServ requires
   far fewer changes to the datapath after the Per Hop Behaviors
   (PHBs) have been configured.
 
   The approach advocated in this draft for the creation of policies
   that control the various QoS mechanisms of networking devices is
   to first identify the attributes with which policies are to be
   constructed.  These attributes are the parameters used in
   expressions that are necessary to construct policies.  There is
   also a parallel desire to define the operators, relations, and
   precedence constructs necessary to construct the conditions and
   actions that constitute these policies.  However, these efforts
   are beyond the scope of this document.
 
 2.2. Specific Needs Of DiffServ
 
   DiffServ-specific rules focus on two particular areas: the core
   and the edges of the network.  As explained in the DiffServ
   Architecture document [R2475], devices at the edge of the network
   classify traffic into different traffic streams.  The core of the
   network then forwards traffic from different streams by using a
   set of Per Hop Behaviors (PHBs).  A DiffServ Code Point (DSCP)
   identifies each PHB.  The DSCP is part of the IP header of each
   packet (as described in [R2474]).  This enables multiple traffic
   streams to be aggregated into a small number of aggregated
   traffic streams, where each aggregate traffic stream is
   identified by a particular DSCP, and forwarded using a particular
   PHB.
 
   The attributes used to manipulate QoS capabilities in the core of
   the network primarily address the behavioral characteristics of
   each supported PHB.  At the edges of the DiffServ network, the
   additional complexities of flow classification, policing, RSVP
   mappings, remarkings, and other factors have to be considered.
   Additional modeling will be required in this area.  However,
   first, the standards for edges of the DiffServ network need more
   detail - to allow the edges to be incorporated into the policy
   model.
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                 [Page 9]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
 2.3. Specific Needs Of IntServ
 
   This document focuses exclusively on the forwarding aspects of
   network QoS.  Therefore, while the forwarding aspects of IntServ
   are considered, the management of IntServ is not considered.
   This topic will be addressed in a future draft.
 
 
 3. Methodology
 
   There is a clear need to define attributes and behavior that
   together define how traffic should be conditioned.  This draft
   defines a set of classes and relationships that represent the QoS
   mechanisms used to condition traffic; [QPIM] is used to define
   policies to control the QoS mechanisms defined in this draft.
 
   However, some very basic issues need to be considered when
   combining these drafts.  Considering these issues should help in
   constructing a schema for managing the operation and
   configuration of network QoS mechanisms through the use of QoS
   policies.
 
 3.1. Level of Abstraction for Expressing QoS Policies
 
   The first issue requiring consideration is the level of
   abstraction at which QoS policies should be expressed. If we
   consider policies as a set of rules used to react to events and
   manipulate attributes or generate new events, we realize that
   policy represents a continuum of specifications that relate
   business goals and rules to the conditioning of traffic done by a
   device or a set of devices. An example of a business level policy
   might be: from 1:00 pm PST to 7:00 am EST, sell off 40% of the
   network capacity on the open market. In contrast, a device-
   specific policy might be: if the queue depth grows at a geometric
   rate over a specified duration, trigger a potential link failure
   event.
 
   A general model for this continuum is shown in Figure 1 below.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 10]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
    +---------------------+
    | High-Level Business |    Not directly related to device
    |     Policies        |    operation and configuration details
    +---------------------+
              |
              |
    +---------V-----------+
    | Device-Independent  |    Translate high-level policies to
    |       Policies      |    generic device operational and
    +---------------------+    configuration information
              |
              |
    +---------V-----------+
    |   Device-Dependent  |    Translate generic device information
    |       Policies      |    to specify how particular devices
    +---------------------+    should operate and be configured
 
 
  Figure 1.  The Policy Continuum
 
   High-level business policies are used to express the requirements
   of the different applications, and prioritize which applications
   get "better" treatment when the network is congested.  The goal,
   then, is to use policies to relate the operational and
   configuration needs of a device directly to the business rules
   that the network administrator is trying to implement in the
   network that the device belongs to.
 
   Device-independent policies translate business policies into a
   set of generalized operational and configuration policies that
   are independent of any specific device, but dependent on a
   particular set of QoS mechanisms, such as RED dropping or
   weighted round robin scheduling.  Not only does this enable
   different types of devices (routers, switches, hosts, etc.) to be
   controlled by QoS policies, it also enables devices made by
   different vendors that use the same types of QoS mechanisms to be
   controlled.  This enables these different devices to each supply
   the correct relative conditioning to the same type of traffic.
 
   In contrast, device-dependent policies translate device-
   independent policies into ones that are specific for a given
   device.  The reason that a distinction is made between device-
   independent and device-dependent policies is that in a given
   network, many different devices having many different
   capabilities need to be controlled together.  Device-independent
   policies provide a common layer of abstraction for managing
   multiple devices of different capabilities, while device-
   dependent policies implement the specific conditioning that is
   required.  This draft provides a common set of abstractions for
   representing QoS mechanisms in a device-independent way.
 
   This draft is focused on the device-independent representation of
   QoS mechanisms. QoS mechanisms are modeled in sufficient detail
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 11]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   to provide a common device-independent representation of QoS
   policies. They can also be used to provide a basis for
   specialization, enabling each vendor to derive a set of vendor-
   specific classes that represent how traffic conditioning is done
   for that vendorÆs set of devices.
 
 3.2. Specifying Policy Parameters
 
   Policies are a function of parameters (attributes) and operators
   (boolean, arithmetic, relational, etc.).  Therefore, both need to
   be defined as part of the same policy in order to correctly
   condition the traffic.  If the parameters of the policy are
   specified too narrowly, they will reflect the individual
   implementations of QoS in each device.  As there is currently
   little consensus in the industry on what the correct
   implementation model for QoS is, most defined attributes would
   only be applicable to the unique characteristics of a few
   individual devices.  Moreover, standardizing all of these
   potential implementation alternatives would be a never-ending
   task as new implementations continued to appear on the market.
 
   On the other hand, if the parameters of the policy are specified
   too broadly, it is impossible to develop meaningful policies.
   For example, if we concentrate on the so-called Olympic set of
   policies, a business policy like "Bob gets Gold Service," is
   clearly meaningless to the large majority of existing devices.
   This is because the device has no way of determining who Bob is,
   or what QoS mechanisms should be configured in what way to
   provide Gold service.
 
   Furthermore, Gold service may represent a single service, or it
   may identify a set of services that are related to each other.
   In the latter case, these services may have different
   conditioning characteristics.
 
   This draft defines a set of parameters that fit into a canonical
   model for modeling the elements in the forwarding path of a
   device implementing QoS traffic conditioning.  By defining this
   model in a device-independent way, the needed parameters can be
   appropriately abstracted.
 
 3.3. Specifying Policy Services
 
   Administrators want the flexibility to be able to define traffic
   conditioning without having to have a low-level understanding of
   the different QoS mechanisms that implement that conditioning.
   Furthermore, administrators want the flexibility to group
   different services together, describing a higher-level concept
   such as "Gold Service".  This higher-level service could be
   viewed as providing the processing to deliver "Gold" quality of
   service.
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 12]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   These two goals dictate the need for the following set of
   abstractions:
 
      o    a flexible way to describe a service
 
      o    must be able to group different services that may use
           different technologies (e.g., DiffServ and 802.1Q)
           together
 
      o    must be able to define a set of sub-services that
           together make up a higher-level service
 
      o    must be able to associate a service and the set of QoS
           mechanisms that are used to condition traffic for that
           service
 
      o    must be able to define policies that manage the QoS
           mechanisms used to implement a service.
 
   This draft addresses this set of problems by defining a set of
   classes and associations that can represent abstract concepts
   like "Gold Service," and bind each of these abstract services to
   a specific set of QoS mechanisms that implement the conditioning
   that they require.  Furthermore, this draft defines the concept
   of "sub-services," to enable Gold Service to be defined either as
   a single service or as a set of services that together should be
   treated as an atomic entity.
 
   Given these abstractions, policies (as defined in [QPIM]) can be
   written to control the QoS mechanisms and services defined in
   this draft.
 
 3.4. Level of Abstraction for Defining QoS Attributes and Classes
 
   This draft defines a set of classes and properties to support
   policies that configure device QoS mechanisms.  This draft
   concentrates on the representation of services in the datapath
   that support both DiffServ (for aggregate traffic conditioning)
   and IntServ (for flow-based traffic conditioning).  Classes and
   properties for modeling IntServ admission control services may be
   defined in a future draft.
 
   The classes and properties in this draft are designed to be used
   in conjunction with the QoS policy classes and properties defined
   in [QPIM].  For example, to preserve the delay characteristics
   committed to an end-user, a network administrator may wish to
   create policies that monitor the queue depths in a device, and
   adjust resource allocations when delay budgets are at risk
   (perhaps as a result of a network topology change).  The classes
   and properties in this document define the specific services and
   mechanisms required to implement those services.  The classes and
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 13]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   properties defined in [QPIM] provide the overall structure of the
   policy that manages and configures this service.
 
   This combination of low-level specification (using this draft)
   and high-level structuring (using [QPIM]) of network services
   enables network administrators to define new services required of
   the network, that are directly related to business goals, while
   ensuring that such services can be managed.  However, this goal
   (of creating and managing service-oriented policies) can only be
   realized if policies can be constructed that are capable of
   supporting diverse implementations of QoS.  The solution is to
   model the QoS capabilities of devices at the behavioral level.
   This means that for traffic conditioning services realized in the
   datapath, the model must support the following characteristics:
 
      o    modeling of a generic network service that has QoS
           capabilities
 
      o    modeling of how the traffic conditioning itself is
           defined
 
      o    modeling of how statistics are gathered to monitor QoS
           traffic conditioning services - this facet of the model
           will be added in a future draft.
 
   This draft models a network service, and associates it with one
   or more QoS mechanisms that are used to implement that service.
   It also models in a canonical form the various components that
   are used to condition traffic, such that standard as well as
   custom traffic conditioning services may be described.
 
 3.5. Characterization of QoS Properties
 
   The QoS properties and classes will be described in more detail
   in Section 4.  However, we should consider the basic
   characteristics of these properties, to understand the
   methodology for representing them.
 
   There are essentially two types of properties, state and
   configuration.  Configuration properties describe the desired
   state of a device, and include properties and classes for
   representing desired or proposed thresholds, bandwidth
   allocations, and how to classify traffic.  State properties
   describe the actual state of the device.  These include
   properties to represent the current operational values of the
   attributes in devices configured via the configuration
   properties, as well as properties that represent state (queue
   depths, excess capacity consumption, loss rates, and so forth).
 
   In order to be correlated and used together, these two types of
   properties must be modeled using a common information model. The
   possibility of modeling state properties and their corresponding
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 14]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   configuration settings is accomplished using the same classes in
   this model - although individual instances of the classes would
   have to be appropriately named or placed in different containers
   to distinguish current state values from desired configuration
   settings.
 
   State information is addressed in a very limited fashion by
   QDDIM.  Currently, only CurrentQueueDepth is proposed as an
   attribute on QueuingService.  The majority of the model is
   related to configuration.  Given this fact, it is assumed that
   this model is a direct memory map into a device.  All
   manipulation of model classes and properties directly affects the
   state of the device.  If it is desired to also use these classes
   to represent desired configuration, that is left to the
   discretion of the implementor.
 
   It is acknowledged that additional properties are needed to
   completely model current state.  However, many of the properties
   defined in this draft represent exactly the state variables that
   will be configured by the configuration properties.  Thus, the
   definition of the configuration properties has an exact
   correspondence with the state properties, and can be used in
   modeling both actual (state) and desired/proposed configuration.
 
 
 3.6. QoS Information Model Derivation
 
   The question of context also leads to another question: how does
   the information specified in the core and QoS policy models
   ([PCIM], [PCIME], and [QPIM], respectively) integrate with the
   information defined in this draft?  Put another way, where should
   device-independent concepts that lead to device-specific QoS
   attributes be derived from?
 
   Past thinking was that QoS was part of the policy model.  This
   view is not completely accurate, and it leads to confusion.  QoS
   is a set of services that can be controlled using policy.  These
   services are represented as device mechanisms.  An important
   point here is that QoS services, as well as other types of
   services (e.g., security), are provided by the mechanisms
   inherent in a given device.  This means that not all devices are
   indeed created equal.  For example, although two devices may have
   the same type of mechanism (e.g., a queue), one may be a simple
   implementation (i.e., a FIFO queue) whereas one may be much more
   complex and robust (i.e., CBWFQ).  However, both of these devices
   can be used to deliver QoS services, and both need to be
   controlled by policy.  Thus, a device-independent policy can
   instruct the devices to queue certain traffic, and a device-
   specific policy can be used to control the queuing in each
   device.
 
   Furthermore, policy is used to control these mechanisms, not to
   represent them.  For example, QoS services are implemented with
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 15]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   classifiers, meters, markers, droppers, queues, and schedulers.
   Similarly, security is also a characteristic of devices, as
   authentication and encryption capabilities represent services
   that networked devices perform (irrespective of interactions with
   policy servers).  These security services may use some of the
   same mechanisms that are used by QoS services, such as the
   concepts of filters.  However, they will mostly require different
   mechanisms than the ones used by QoS, even though both sets of
   services are implemented in the same devices.
 
   Thus, the similarity between the QoS model and models for other
   services is not so much that they contain a few common
   mechanisms.  Rather, they model how a device implements their
   respective services.  As such, the modeling of QoS should be part
   of a networking device schema rather than a policy schema.  This
   allows the networking device schema to concentrate on modeling
   device mechanisms, and the policy schema to focus on the
   semantics of representing the policy itself (conditions, actions,
   operators, etc.).  While this draft concentrates on defining an
   information model to represent QoS services in a device datapath,
   the ultimate goal is to be able to apply policies that control
   these services in network devices.  Furthermore, these two
   schemata (device and policy) must be tightly integrated in order
   to enable policy to control QoS services.
 
 3.7. Attribute Representation
 
   The last issue to be considered is the question of how attributes
   are represented.  If QoS attributes are represented as absolute
   numbers (e.g., Class AF2 gets 2 Mbs of bandwidth), it is more
   difficult to make them uniform across multiple ports in a device
   or across multiple devices, because of the broad variation in
   link capacities. However, expressing attributes in relative or
   proportional terms (e.g., Class AF2 gets 5% of the total link
   bandwidth) makes it more difficult to express certain types of
   conditions and actions, such as:
 
       (If ConsumedBandwidth = AssignedBandwidth Then ...)
 
   There are really three approaches to addressing this problem:
 
      o    Multiple properties can be defined to express the same
           value in various forms. This idea has been rejected
           because of the difficulty in keeping these different
           properties synchronized (e.g., when one property changes,
           the others all have to be updated).
 
      o    Multi-modal properties can be defined to express the same
           value, in different terms, based on the access or
           assignment mode. This option was rejected because it
           significantly complicates the model and is impossible to
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 16]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
           express in current directory access protocols (e.g.,
           (L)DAP).
 
      o    Properties can be expressed as "absolutes", but the
           operators in the policy schema would need to be more
           sophisticated. Thus, to represent a percentage, division
           and multiplication operators are required (e.g., Class
           AF2 gets .05 * the total link bandwidth). This is the
           approach that has been taken in this draft.
 
 3.8. Mental Model
 
   The mental model for constructing this schema is based on the
   work done in the Differentiated Services working group.  This
   schema is based on information provided in the current versions
   of the DiffServ Informal Management Model [DSMODEL], the DiffServ
   MIB [DSMIB], the PIB [PIB], as well as on information in the set
   of RFCs that constitute the basic definition of DiffServ itself
   ([R2475], [R2474], [R2597], and [R2598]).  In addition, a common
   set of terminology is available in [POLTERM].
 
   Note that this work is not yet completely aligned, as there are
   differences among the DiffServ Informal Management Model, the
   DiffServ MIB, the DiffServ PIB, and this draft.  Work to finish
   aligning these drafts is in progress, and will be reflected in
   the next revision of this draft.
 
   This model is built around two fundamental class hierarchies that
   are bound together using a set of associations.  The two class
   hierarchies derive from the QoSService and ConditioningService
   base classes.  A set of associations relate lower-level
   QoSService subclasses to higher-level QoSServices, relate
   different types of ConditioningServices together in processing a
   traffic class, and relate a set of ConditioningServices to a
   specific QoSService.  This combination of associations enables us
   to view the device as providing a set of services that can be
   configured, in a modular building block fashion, to construct
   application-specific services.  Thus, this document can be used
   to model existing and future standard as well as application-
   specific network QoS services.
 
 3.8.1. The QoSService Class
 
   The first of the classes defined here, QoSService, is used to
   represent higher-level network services that require special
   conditioning of their traffic.  An instance of QoSService (or one
   of its subclasses) is used to bring together a group of
   conditioning services which, from the perspective of the system
   manager, are all used to deliver a common service.  Thus, the set
   of classifiers, markers, and related conditioning services that
   provide premium service to the "selected" set of user traffic may
   be grouped together into a premium QoSService.
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 17]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   QoSService has a set of subclasses that represent different
   approaches to delivering IP services.  The currently defined set
   of subclasses are a FlowService for flow oriented QoS delivery
   and a DiffServService for DiffServ aggregate oriented QoS service
   delivery.
 
   The QoS services can be related to each other as peers, or they
   can be implemented as subservient services to each other.  The
   QoSSubService aggregation indicates that one or more QoSService
   objects are subservient to a particular QoSService object.  For
   example, this enables us to define Gold Service as a combination
   of two DiffServServices, one for high quality traffic treatment,
   and one for servicing the rest of the traffic.  Each QoSService
   would be associated with a set of classifiers, markers, etc, such
   that the high quality traffic would get EF marking and
   appropriate queuing.
 
   The DiffServService itself has an AFService subclass.  This
   subclass is used to represent the specific notion that several
   related markings within the AF PHB Group work together to provide
   a single service.  When other DiffServ PHB Groups are defined
   which use more than one code point, these will be likely
   candidates for additional DiffServService subclasses.
 
   Technology-specific mappings of these services, representing the
   specific use of PHB marking or 802.1Q marking, are captured
   within the ConditioningServices rather than in the QoSServices
   themselves.
 
   These concepts are depicted in Figure 2.  Note that both of the
   associations are aggregations: a QoSService aggregates both the
   set of QoSServices subservient to it, and the set of
   ConditioningServices that realize it.  See Section 4 for class
   and association definitions.
 
 
 
                  /\______
             0..1 \/      |
     +--------------+     | QoSSubService     +---------------+
     |              |0..n |                   |               |
     |  QoSService  |-----                    | Conditioning  |
     |              |                         |   Service     |
     |              |                         |               |
     |              |0..n                 0..n|               |
     |              | /\______________________|               |
     |              | \/  QoSConditioning     |               |
     +--------------+       SubService        +---------------+
 
 
  Figure 2.  QoSService and its Aggregations
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 18]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
 3.8.2. The ConditioningService Class
 
   The goal of the ConditioningService classes is to describe the
   sequence of traffic conditioning that is applied to a given
   traffic stream on the ingress interface through which it enters a
   device, and then on the egress interface through which it leaves
   the device.  This is done using a set of classes and
   relationships.  The routing decision in the device core, which
   selects which egress interface a particular packet will use, is
   not represented in this model.
 
   A single base class, ConditioningService, is the superclass for a
   set of subclasses representing the mechanisms that condition
   traffic.  These subclasses define device-independent conditioning
   primitives (including classifiers, meters, markers, droppers,
   queues, and schedulers) that together implement the conditioning
   of traffic on an interface.  This model abstracts these services
   into a common set of modular building blocks that can be used,
   regardless of device implementation, to model the traffic
   conditioning internal to a device.
 
   The different conditioning mechanisms need to be related to each
   other to describe how traffic is conditioned.  Several important
   variations of how these services are related together exist:
 
      o    A particular ingress or egress interface may not require
           all the types of ConditioningServices.
 
      o    Multiple instances of the same mechanism may be required
           on an ingress or egress interface.
 
      o    There is no set order of application for the
           ConditioningServices on an ingress or egress interface.
 
   Therefore, this model does not dictate a fixed ordering among the
   subclasses of ConditioningService, or identify a subclass of
   ConditioningService that must appear first or last among the
   ConditioningServices on an ingress or egress interface.  Instead,
   this model ties together the various ConditioningService
   instances on an ingress or egress interface using the
   NextService, NextServiceAfterMeter, and
   NextServiceAfterConditioningElement associations.  There are also
   separate associations, called
   IngressConditioningServiceOnEndpoint and
   EgressConditioningServiceOnEndpoint, which, respectively, tie an
   ingress interface to its first ConditioningService, and tie an
   egress interface to its last ConditioningService(s).
 
 
 
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 19]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
 3.8.3. Preserving QoS Information from Ingress to Egress
 
   There is one important way in which the QDDIM model diverges from
   the [DSMODEL].  In [DSMODEL], traffic passes through a network
   device in three stages:
 
      o    It comes in on an ingress interface, where it may receive
           QoS conditioning.
      o    It traverses the routing core, where logic outside the
           scope of QoS determines which egress interface it will
           use to leave the device.
      o    It may receive further QoS conditioning on the selected
           egress interface, and then it leaves the device.
 
   In this model, no information about the QoS conditioning that a
   packet receives on the ingress interface is communicated with the
   packet across the routing core to the egress interface.
 
   The QDDIM model relaxes this restriction, to allow information
   about the treatment that a packet received on an ingress
   interface to be communicated along with the packet to the egress
   interface.  (This relaxation adds a capability that is present in
   many network devices.)  QDDIM represents this information
   transfer in terms of a packet preamble, which is how many devices
   implement it.  But implementations are free to use other
   mechanisms to achieve the same result.
 
         +---------+
         | Meter-A |
      a  |         | b      d
     --->|      In-|---PM-1--->
         |         | c      e
         |     Out-|---PM-2--->
         +---------+
 
  Figure 3:  Meter Followed by Two Preamble Markers
 
   Figure 3 shows an example in which meter results are captured in
   a packet preamble.  The arrows labeled with single letters
   represent instances of either the NextService association (a, d,
   and e), or of its  peer association NextServiceAfterMeter (b and
   c).  PreambleMarker PM-1 adds to the packet preamble an
   indication that the packet exited Meter A as conforming traffic.
   Similarly, PreambleMarker PM-2 adds to the preambles of packets
   that come through it indications that they exited Meter A as
   nonconforming traffic.  A PreambleMarker appends its information
   to whatever is already present in a packet preamble, as opposed
   to overwriting what is already there.
 
   To foster interoperability, the basic format of the information
   captured by a PreambleMarker is specified.  (Implementations, of
   course, are free to represent this information in a different way
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 20]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
   internally - this is just how it is represented in the model.)
   The information is represented by an ordered, multi-valued string
   property FilterItemList, where each individual value of the
   property is of the form "<type>,<value>".  When a PreambleMarker
   "appends" its information to the information that was already
   present in a packet preamble, it does so by adding additional
   items of the indicated format to the end of the list.
 
   QDDIM provides a limited set of standardized <type>'s that a
   PreambleMarker may use:
 
      o    ConformingFromMeter: the value is the name of the meter.
      o    PartConformingFromMeter: the value is the name of the
           meter.
      o    NonConformingFromMeter: the value is the name of the
           meter.
      o    VlanId: the value is the VLAN ID.
 
   Implementations may recognize other <type>'s in addition to
   these.  If collisions of implementation-specific <type>'s become
   a problem, it is possible that <type>'s may become an IANA-
   administered range in a future revision of this standard.
 
   To make use of the information that a PreambleMarker stores in a
   packet preamble, a specific subclass PreambleFilter of
   FilterEntryBase is defined, to match on the "<type>,<value>"
   strings.  To simplify the case where there's just a single level
   of metering in a device, but different individual meters on each
   ingress interface, PreambleFilter allows a wildcard "any" for the
   <value> part of the three meter-related filters.  With this
   wildcard, an administrator can specify a Classifier to select all
   packets that were found to be conforming (or partially
   conforming, or non-conforming) by their respective meters,
   without having to name each meter individually in a separate
   ClassifierElement.
 
   Once a meter result has been stored in a packet preamble, it is
   available for any subsequent Classifier to use.  So while the
   motivation for this capability has been described in terms of
   preserving QoS conditioning information from an ingress interface
   to an egress interface, a prior meter result may also be used for
   classifying packets later in the datapath on the same interface
   where the meter resides.
 
 
 3.9. Classifiers, FilterLists, and Filter Entries
 
   This draft uses a number of classes to model the classifiers
   defined in [DSMODEL]: ClassifierService, ClassifierElement,
   FilterList, FilterEntryBase, and various subclasses of
   FilterEntryBase.  There are also two associations involved:
   ClassifierElementUsesFilterList and EntriesInFilterList.  The
   QDDIM model makes no use of CIM's FilterEntry class.
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 21]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   In [DSMODEL], a single traffic stream coming into a classifier is
   split into multiple traffic streams leaving it, based on which of
   an ordered set of filters each packet in the incoming stream
   matches.  A filter matches either a field in the packet itself,
   or possibly other attributes associated with the packet.  In the
   case of a multi-field (MF) classifier, packets are assigned to
   output streams based on the contents of multiple fields in the
   packet header.  For example, an MF classifier might assign
   packets to an output stream based on their complete IP-addressing
   5-tuple.
 
   To optimize the representation of MF classifiers, subclasses of
   FilterEntryBase are introduced, which allow multiple related
   packet header fields to be represented in a single object.  These
   subclasses are IPHeaderFilter and 8021Filter.  With
   IPHeaderFilter, for example, criteria for selecting packets based
   on all five of the IP 5-tuple header fields and the DiffServ DSCP
   can be represented by a FilterList containing one IPHeaderFilter
   object.  Because these two classes have applications beyond those
   considered in this draft, they, as well as the abstract class
   FilterEntryBase, are defined in the more general draft [PCIME]
   rather than here.
 
   The FilterList object is always needed, even if it contains only
   one filter entry (that is, one FilterEntryBase subclass) object.
   This is because a ClassifierElement can only be associated with a
   Filter List, as opposed to an individual FilterEntry.  FilterList
   is also defined in [PCIME].
 
   The EntriesInFilterList aggregation (also defined in [PCIME]) has
   a property EntrySequence, which in the past (in CIM) could be
   used to specify an evaluation order on the filter entries in a
   FilterList.  Now, however, the EntrySequence property supports
   only a single value: '0'.  This value indicates that the
   FilterEntries are ANDed together to determine whether a packet
   matches the MF selector that the FilterList represents.
 
   A ClassifierElement specifies the starting point for a specific
   policy or data path.  Each ClassifierElement uses the
   NextServiceAfterClassifierElement association to determine the
   next conditioning service to apply for packets to.
 
   A ClassifierService defines a grouping of ClassifierElements.
   There are certain instances where a ClassifierService actually
   specifies an aggregation of ClassifierServices. One practical
   case would be where each ClassifierService specifies a group of
   policies associated with a particular application and another
   ClassifierService groups the application-specific
   ClassifierService instances. In this particular case, the
   application-specific ClassifierService instances are specified
   once, but unique combinations of these ClassifierServices are
   specified, as needed, using other ClassifierService instances.
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 22]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   ClassifierService instances grouping other ClassifierService
   instances may not specify a FilterList using the
   ClassifierElementUsesFilterList association. This special use of
   ClassifierService serves just as a Classifier collecting
   function.
 
 3.10. Modeling of Droppers
 
   In [DSMODEL], a distinction is made between absolute droppers and
   algorithmic droppers.  In QDDIM, both of these types of droppers
   are modeled with the DropperService class, or with one of its
   subclasses.  In both cases, the queue from which the dropper
   drops packets is tied to the dropper by an instance of the
   NextService association.  The dropper always plays the
   PrecedingService role in these associations, and the queue always
   plays the FollowingService role.  There is always exactly one
   queue from which a dropper drops packets.
 
   Since an absolute dropper drops all packets in its queue, it
   needs no configuration beyond a NextService tie to that queue.
   For an algorithmic dropper, however, further configuration is
   needed:
 
      o    a specific drop algorithm;
      o    parameters for the algorithm (for example, token bucket
           size);
      o    the source(s) of input(s) to the algorithm;
      o    possibly per-input parameters for the algorithm.
 
   The first two of these items are represented by properties of the
   DropperService class, or properties of one of its subclasses.
   The last two, however, involve additional classes and
   associations.
 
 3.10.1. Configuring Head and Tail Droppers
 
   The HeadTailDropQueueBinding is the association that identifies
   the inputs for the algorithm executed by a tail dropper.  This
   association is not used for a head dropper, because a head
   dropper always has exactly one input to its drop algorithm, and
   this input is always the queue from which it drops packets.  For
   a tail dropper, this association is defined to have a many-to-
   many cardinality.  There are, however, two distinct cases:
 
   One dropper bound to many queues: This represents the case where
   the drop algorithm for the dropper involves inputs from more than
   one queue.  The dropper still drops from only one queue, the one
   to which it is tied by a NextService association.  But the drop
   decision may be influenced by the state of several queues.  For
   the classes HeadTailDropper and HeadTailDropQueueBinding, the
   rule for combining the multiple inputs is simple addition: if the
   sum of the lengths of the monitored queues exceeds the dropper's
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 23]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   QueueThreshold value, then packets are dropped.  This rule for
   combining inputs may, however, be overridden by a different rule
   in subclasses of one or both of these classes.
 
   One queue bound to many droppers: This represents the case where
   the state of one queue (which is typically also the queue from
   which packets are dropped) provides an input to multiple
   droppers' drop algorithms.  A use case here is a classifier that
   splits a traffic stream into, say, four parts, representing four
   classes of traffic.  Each of the parts goes through a separate
   HeadTailDropper, then they're re-merged onto the same queue.  The
   net is a single queue containing packets of four traffic types,
   with, say, the following drop thresholds:
 
      o    Class 1 - 90% full
      o    Class 2 - 80% full
      o    Class 3 - 70% full
      o    Class 4 - 50% full
 
  Here the percentages represent the overall state of the queue.
  With this configuration, when the queue in question becomes 50%
  full, Class 4 packets will be dropped rather than joining the
  queue, when it becomes 70% full, Class 3 and 4 packets will be
  dropped, etc.
 
  The two cases described here can also occur together, if a
  dropper receives inputs from multiple queues, one or more of
  which are also providing inputs to other droppers.
 
 3.10.2. Configuring RED Droppers
 
   Like a tail dropper, a RED dropper, represented by an instance of
   the REDDropperService class, may take as its inputs the states of
   multiple queues.  In this case, however, there is an additional
   step: each of these inputs may be smoothed before the RED dropper
   uses it, and the smoothing process itself must be parameterized.
   Consequently, in addition to REDDropperService and
   QueuingService, a third class, DropThresholdCalculationService,
   is introduced, to represent the per-queue parameterization of
   this smoothing process.
 
   The following instance diagram illustrates how these classes work
   with each other:
 
 
 
 
 
 
 
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 24]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
                   RDSvc-A
                   |  |  |
             +-----+  |  +-----+
             |        |        |
           DTCS-1   DTCS-2   DTCS-3
             |        |        |
            Q-1      Q-2      Q-3
 
  Figure 4. Inputs for a RED Dropper
 
   So REDDropperService-A (RDSvc-A) is using inputs from three
   queues to make its drop decision.  (As always, RDSvc-A is linked
   to the queue from which it drops packets via the NextService
   association.)  For each of these three queues, there is a
   (DropThresholdCalculationService) DTCS instance that represents
   the smoothing weight and time interval to use when looking at
   that queue.  Thus each DTCS instance is tied to exactly one
   queue, although a single queue may be examined (with different
   weight and time values) by multiple DTCS instances.  Also, a DTCS
   instance and the queue behind it can be thought of as a "unit of
   reusability."  So a single DTCS can be referred to by multiple
   RDSvc's.
 
   Unless it is overridden by a different rule in a subclass of
   REDDropperService, the rule that a RED dropper uses to combine
   the smoothed inputs from the DTCS's to create a value to use in
   making its drop decision is simple addition.
 
 
 3.11. Modeling of Queues and Schedulers
 
   In order to appreciate the rationale behind this rather complex
   model for scheduling, we must consider the rather complex nature
   of schedulers, as well as the extreme variations in algorithms
   and implementations.  Although these variations are broad, we
   have identified four examples that serve to test the model and
   justify its complexity.
 
 3.11.1. Simple Hierarchical Scheduler
 
   A simple, hierarchical scheduler has the following properties.
   First, when a scheduling opportunity is given to a set of queues,
   a single, viable queue is determined based on some scheduling
   criteria, such as bandwidth or priority.  The output of the
   scheduler is the input to another scheduler that treats the first
   scheduler (and its queues) as a single logical queue.  Hence, if
   the first scheduler determined the appropriate packet to release
   based on a priority assigned to each queue, the second scheduler
   might specify a bandwidth limit/allocation for the entire set of
   queues aggregated by the first scheduler.
 
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 25]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   +----------+                              NextService
   |QueuingSvc+----------------------------------------------+
   | Name=EF1 |                                              |
   |          | QueueTo    +--------------+ ElementSched     |
   |          +------------+PrioritySched +---------------+  |
   +----------+ Schedule   |Element       | Service       |  |
                           | Name=EF1-Pri |               |  v
                           | Priority=1   |    +-----------+-+-+
                           +--------------+    |SchedulingSvc  +
                                               | Name=PriSched1+
                           +--------------+    +----------+--+-+
                           |PrioritySched | ElementSched  |  ^
   +----------+            |Element       +---------------+  |
   |QueuingSvc| QueueTo    | Name=AF1x-Pri| Service          |
   | Name=AF1x+------------+ Priority=2   |                  |
   |          | Schedule   +--------------+                  |
   |          |                              NextService     |
   |          +----------------------------------------------+
   +----------+
   .
   :
   +---------------+            NextScheduler
   |SchedulingSvc  +--------------------------------------------+
   | Name=PriSched1|                                            |
   +-------+-------+       +--------------------+ElementSchedSvc|
           | SchedToSched  |AllocationScheduling+--------+      |
           +---------------+Element             |        |      |
                           | Name=PriSched1-Band|        |      |
                           | Units=Bytes        |        |      v
                           | Bandwidth=100      | +------+------+--+
                           +--------------------+ |SchedulingSvc   |
                                                  | Name=BandSched1|
                           +--------------------+ +------+------+--+
                           |AllocationScheduling|        |      ^
   +---------------+       |Element             +--------+      |
   |QueuingService |       | Name=BE-Band       |ElementSchedSvc|
   | Name=BE       |QueueTo+ Units=Bytes        |               |
   |               |-------+ Bandwidth=50       |               |
   |               |Sched  +--------------------+               |
   |               |                             NextService    |
   |               +--------------------------------------------+
   +---------------+
 
   Figure 5. Example 1: Simple Hierarchical Scheduler
 
   Figure 5 illustrates the example and how it would be instantiated
   using the model.  In the figure, NextService determines the first
   scheduler after the queue.  NextScheduler determines the
   subsequent ordering of schedulers.  In addition, the
   ElementSchedulingService association determines the set of
   scheduling parameters used by a specific scheduler.  Scheduling
   parameters can be bound either to queues or to schedulers.  In
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 26]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   the case of the SchedulingElement EF1-Pri, the binding is to a
   queue, so the QueueToSchedule association is used.  In the case
   of the SchedulingElement PriSched1-Band, the binding is to
   another scheduler, so the SchedulerToSchedule association is
   used.  Note that due to space constraints of the document, the
   SchedulingService PRISched1 is represented twice, to show how it
   is connected to all the other objects.
 
 3.11.2. Complex Hierarchical Scheduler
 
   A complex, hierarchical scheduler has the same characteristics as
   a simple scheduler, except that the criteria for the second
   scheduler are determined on a per queue basis rather than on an
   aggregate basis.  One scenario might be a set of bounded priority
   schedulers.  In this case, each queue is assigned a relative
   priority.  However, each queue is also not allowed to exceed a
   bandwidth allocation that is unique to that queue.  In order to
   support this scenario, the queue must be bound to two separate
   schedulers.  Figure 6 illustrates this situation, by describing
   an EF queue and a BE queue both pointing to a priority scheduler
   via the NextService association.  The NextScheduler association
   between the priority scheduler and the bandwidth scheduler in
   turn defines the ordering of the scheduling hierarchy.  Also note
   that each scheduler has a distinct set of scheduling parameters
   that are bound back to each queue.  This demonstrates the need to
   support two or more parameter sets on a per queue basis.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 27]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   +----------------+
   |QueuingService  |
   | Name=EF        |
   |                |QueueTo   +----------------+ElementSchedSvc
   |                +----------+AllocationSched +--------+
   ++---+-----------+Schedule  |Element         |        |
    |   |                      | Name=BandEF    |        |
    |   |QueueTo               | Units=Bytes    |        |
    |   |Schedule              | Bandwidth=100  |        |
    |   |                      +----------------+ +------+---------+
    |   |                                         |SchedulingSvc   |
    |   |      +------------------+               | Name=BandSched |
    |   +------+PriorityScheduling|               +------------+--++
    |          |Element           |                            ^  |
    |          | Name=PriEF       |ElementSchedSvc             |  |
    |          | Priority=1       +---------------------+      |  |
    |          +------------------+                     |      |  |
    |NextService                                        |      |  |
    +-------------------------------------------------+ |      |  |
                                                      | |      |  |
     NextService                                      | |      |  |
    +-----------------------------------------------+ | |      |  |
    |                                               | | |      |  |
    |          +------------------+ElementSchedSvc  | | |      |  |
    |          |PriorityScheduling+--------+        | | |      |  |
    |          |Element           |        |        | | |      |  |
    |          | Name=PriBE       |        |        v v |      |  |
    |   +------+ Priority=2       |    +---+--------+-+-+-+Next|  |
    |   |      +------------------+    |SchedulingService +----+  |
    |   |                              | Name=PriSched    |Sched  |
    |   |                              +------------------+       |
    |   |QueueTo                                                  |
    |   |Schedule              +----------------+                 |
    |   |                      |AllocationSched |ElementSchedSvc  |
   +----+---------+            |Element         +-----------------+
   |QueuingService|QueueTo     | Name=BandBE    |
   | Name=BE      +------------+ Units=Bytes    |
   |              |Schedule    | Bandwidth=50   |
   |              |            +----------------+
   +--------------+
 
  Figure 6. Example 2: Complex Hierarchical Scheduler
 
 3.11.3. Excess Capacity Scheduler
 
   An excess capacity scheduler offers a similar requirement to
   support two scheduling parameter sets per queue.  However, in
   this scenario the reasons are a little different.  Suppose a set
   of queues have each been assigned bandwidth limits to ensure that
   no traffic class starves out another traffic class.  The result
   may be that one or more queues have exceeded their allocation
   while the queues that deserve scheduling opportunities are empty.
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 28]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   The question then is how is the excess (idle) bandwidth
   allocated.  Conceivably, the scheduling criteria for excess
   capacity are completely different from the criteria that
   determine allocations under uniform load.  This could be
   supported with a scheduling hierarchy.  However, the problem is
   that the criteria for using the subsequent scheduler are
   different from those in the last two cases.  Specifically, the
   next scheduler should only be used if a scheduling opportunity
   exists that was passed over by the prior scheduler.
 
   When a scheduler chooses to forgo a scheduling decision, it is
   behaving as a non-work conserving scheduler.  Work conserving
   schedulers by definition will always take advantage of a
   scheduling opportunity, irrespective of which queue is being
   serviced and how much bandwidth it has consumed in the past.
   This point leads to an interesting insight.  The semantics of a
   non-work conserving scheduler are equivalent to those of a meter,
   in that if a packet is in profile it is given the scheduling
   opportunity, and if it is out of profile it does not get a
   scheduling opportunity.  However, with meters there are semantics
   that determine the next action behavior when the packet is in
   profile and when the packet is out of profile.  Similarly, with
   the non-work conserving scheduler, there needs to be a means for
   determining the next scheduler when a scheduler chooses not to
   utilize a scheduling opportunity.
 
   Figure 7 illustrates this last scenario.  It appears very similar
   to Figure 6, except that the binding between the allocation
   scheduler and the WRR scheduler is using a FailNextScheduler
   association.  This association is explicitly indicating the fact
   that the only time the WRR scheduler would be used is when there
   are non-empty queues that the allocation scheduler rejected for
   scheduling consideration.  Note that Figure 7 is incomplete, in
   that typically there would be several more queues that are bound
   to an allocation scheduler and a WRR scheduler.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 29]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   +------------+
   |QueuingSvc  |
   | Name=EF    |
   |            |
   |            |
   ++-+---------+
    | |
    | |QueueTo
    | |Schedule                                     +--------------+
    | |                                             |SchedulingSvc |
    | |      +------------------+                   | Name=WRRSched|
    | +------+AllocationSched   |                   +----------+-+-+
    |        |Element           |                              ^ |
    |        | Name=BandEF      |ElementSchedSvc               | |
    |        | Units=Bytes      +--------------------+         | |
    |        | Bandwidth=100    |                    |         | |
    |        +------------------+                    |         | |
    |NextService                                     |         | |
    +----------------------------------------------+ |         | |
                                                   | |         | |
     NextService                                   | |         | |
    +--------------------------------------------+ | |         | |
    |                                            | | |         | |
    |        +------------------+ElementSchedSvc | | |         | |
    |        |AllocationSched   +--------+       | | |         | |
    |        |Element           |        |       | | |         | |
    |        | Name=BandwidthAF1|        |       | | |         | |
    |        | Units=Bytes      |        |       v v |         | |
    | +------+ Bandwidth=50     |  +--+----------+-+-++FailNext| |
    | |      +------------------+  |SchedulingService +--------+ |
    | |QueueTo                     | Name=BandSched   |Scheduler |
    | |Schedule                    +------------------+          |
    | |                                                          |
    | |                       +---------------------+            |
   ++-+-----------+           | WRRSchedulingElement|            |
   |QueuingService|QueueTo    | Name=WRRBE          +------------+
   | Name=BE      +-----------+ Weight=30           |ElementSchedSvc
   +--------------+Schedule   +---------------------+
 
  Figure 7.  Example 3: Excess Capacity Scheduler
 
 3.11.4. Hierarchical CBQ Scheduler
 
   A hierarchical CBQ scheduler is the fourth scenario to be
   considered.  In hierarchical CBQ, each queue is allocated a
   specific bandwidth allocation.  Queues are grouped together into
   a logical scheduler.  This logical scheduler in turn has an
   aggregate bandwidth allocation that equals the sum of the queues
   it is scheduling.  In turn, logical schedulers can be aggregated
   into higher-level logical schedulers.  Changing perspectives and
   looking top down, the top-most logical scheduler has 100% of the
   link capacity.  This allocation is parceled out to logical
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 30]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   schedulers below it such that the sum of the allocations is equal
   to 100%.  These second tier schedulers may in turn parcel out
   their allocation across a third tier of schedulers and so forth
   until the lowest tier that parcels out their allocations to
   specific queues representing relatively fine-grained classes of
   traffic.  The unique aspect of hierarchical CBQ is that when
   there is insufficient bandwidth for a specific allocation,
   schedulers higher in the tree are tested to see if another
   portion of the tree has capacity to spare.
 
   Figure 8 demonstrates this example with two tiers.  The example
   is split in half because of space constraints, resulting in the
   CBQTier1 scheduling service instance being represented twice.
   Note that the total allocation at the top tier is 50 Mb.  The
   voice allocation is 22 Mb.  The remaining 23 Mb is split between
   FTP and Web.  Hence, if Web traffic is actually consuming 20 Mb
   (5 Mb in excess of the allocation).  If FTP is consuming 5 Mb,
   then it is possible for the CBQTier1 scheduler to offer 3Mb of
   its allocation to Web traffic.  However, this is not enough, so
   the FailNextScheduler association needs to be traversed to
   determine if there is any excess capacity available from the
   voice class.  If the voice class is only consuming 15 Mb of its
   22 Mb allocation, there are sufficient resources to allow the web
   traffic through.  Note that FailNextScheduler is used as the
   association.  The reason is because the CBQTier1 scheduler in
   fact failed to schedule a packet because of insufficient
   resources.  It is conceivable that a variant of hierarchical CBQ
   allows a hierarchy for successful scheduling as well.  Hence,
   both associations are necessary.
 
   Note that due to space constraints of the document, the
   SchedulingService CBQTier1 is represented twice, to show how it
   is connected to all the other objects.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 31]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   +-----------+                        NextService
   |QueuingSvc +-------------------------------------------+
   | Name=Web  |                                           |
   |           |QueueTo+----------------+ ElementSchedSvc  |
   |           +-------+AllocationSched +----------------+ |
   +-----------+Sched  |Element         |                | |
                       | Name=Web-Alloc |                | v
                       | Bandwidth=15   |    +-----------+-+-+
                       +----------------+    |SchedulingSvc  +
                                             | Name=CBQTier1 +
                       +----------------+    +-----------+-+-+
                       |AllocationSched | ElementSchedSvc| ^
   +-----------+       |Element         +----------------+ |
   |QueuingSvc |QueueTo| Name=FTP-Alloc |                  |
   | Name=FTP  +-------+ Bandwidth=8    |                  |
   |           |Sched  +----------------+                  |
   |           |                        NextService        |
   |           +-------------------------------------------+
   +-----------+
   .
   :
 
   +---------------+                    FailNextScheduler
   |SchedulingSvc  +---------------------------------------------+
   | Name=CBQTier1 |                                             |
   +-------+-------+       +---------------------+ElementSchedSvc|
           | SchedToSched  |AllocationScheduling +--------+      |
           +---------------+Element              |        |      |
                           | Name=LowPri-Alloc   |        |      |
                           | Bandwidth=23        |        |      v
                           +---------------------+  +-----+------+-+
                                                    |SchedulingSvc |
                                                    | Name=CBQTop  |
                        +---------------------+     +----------+-+-+
                        |AllocationScheduling |ElementSchedSvc | ^
   +------------+       |Element              +----------------+ |
   |QueuingSvc  |QueueTo| Name=BE-Band        |                  |
   | Name=Voice +-------+ Bandwidth=22        |                  |
   |            |Sched  +---------------------+                  |
   |            |                       NextService              |
   |            +------------------------------------------------+
   +------------+
 
  Figure 8.  Example 4: Hierarchical CBQ Scheduler
 
 
 4. The Class Hierarchy
 
   The following sections present the class and association
   hierarchies that together comprise the information model for
   modeling QoS capabilities at the device level.
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 32]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
 4.1. Associations and Aggregations
 
   Associations and aggregations are a means of representing
   relationships between two (or theoretically more) objects.
   Dependency, aggregation, and other relationships are modeled as
   classes containing two (or more) object references.  It should be
   noted that aggregations represent either "whole-part" or
   "collection" relationships.  For example, aggregation can be used
   to represent the containment relationship between a system and
   the components that constitute the system.
 
   Since associations and aggregations are classes, they can benefit
   from all of the object-oriented features that other non-
   relationship classes have.  For example, they can contain
   properties and methods, and inheritance can be used to refine
   their semantics such that they represent more specialized types
   of their superclasses.
 
   Note that an association (or an aggregation) object is treated as
   an atomic unit (individual instance), even though it
   relates/collects/is comprised of multiple objects.  This is a
   defining feature of an association (or an aggregation) - although
   the individual elements that are related to other objects have
   their own identities, the association (or aggregation) object
   that is constructed using these objects has its own identity and
   name as well.
 
   It is important to note that associations and aggregations form
   an inheritance hierarchy that is separate from the class
   inheritance hierarchy.  Although associations and aggregations
   are typically bi-directional, there is nothing that prevents
   higher order associations or aggregations from being defined.
   However, such associations and aggregations are inherently more
   complex to define, understand, and use.  In practice,
   associations and aggregations of orders higher than binary are
   rarely used, because of their greatly increased complexity and
   lack of generality.  All of the associations and aggregations
   defined in this model are binary.
 
   Note also that by definition, associations and aggregations
   cannot be unary.
 
 
   Finally, note that associations and aggregations that are defined
   between two classes do not affect the classes themselves.  That
   is, the addition or deletion of an association or an aggregation
   does not affect the interfaces of the classes that it is
   connecting.
 
 4.2. The Structure of the Class Hierarchies
 
   The structure of the class, association, and aggregation class
   inheritance hierarchies for managing the datapaths of QoS devices
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 33]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   is shown, respectively, in Figure 9, Figure 10, and Figure 11.
   The notation (CIMCORE) identifies a class defined in the CIM Core
   model.  Please refer to [CIM] for the definitions of these
   classes.  Similarly, the notation [PCIME] identifies a class
   defined in the Policy Core Information Model Extensions draft.
   This model has been influenced by [CIM], and is compatible with
   the Directory Enabled Networks (DEN) effort.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 34]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
  +--ManagedElement (CIMCORE)
     |
     +--ManagedSystemElement (CIMCORE)
     |  |
     |  +--LogicalElement (CIMCORE)
     |     |
     |     +--Service (CIMCORE)
     |     |  |
     |     |  +--ConditioningService
     |     |  |  |
     |     |  |  +--ClassifierService
     |     |  |  |  |
     |     |  |  |  +--ClassifierElement
     |     |  |  |
     |     |  |  +--MeterService
     |     |  |  |  |
     |     |  |  |  +--AverageRateMeterService
     |     |  |  |  |
     |     |  |  |  +--EWMAMeterService
     |     |  |  |  |
     |     |  |  |  +--TokenBucketMeterService
     |     |  |  |
     |     |  |  +--MarkerService
     |     |  |  |  |
     |     |  |  |  +--PreambleMarkerService
     |     |  |  |  |
     |     |  |  |  +--TOSMarkerService
     |     |  |  |  |
     |     |  |  |  +--DSCPMarkerService
     |     |  |  |  |
     |     |  |  |  +--8021QMarkerService
     |     |  |  |
     |     |  |  +--DropperService
     |     |  |  |  |
     |     |  |  |  +--HeadTailDropperService
     |     |  |  |  |
     |     |  |  |  +--RedDropperService
     |     |  |  |
     |     |  |  +--QueuingService
     |     |  |  |
     |     |  |  +--PacketSchedulingService
     |     |  |     |
     |     |  |     +--NonWorkConservingSchedulingService
     |     |  |
     |     |  +--QoSService
     |     |  |  |
     |     |  |  +--DiffServService
     |     |  |  |   |
     |     |  |  |   +--AFService
     |     |  |  |
     |     |  |  +--FlowService
  (continued on following page)
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 35]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
  (continued from previous page;
   the first four elements are repeated for convenience)
 
  +--ManagedElement (CIMCORE)
     |
     +--ManagedSystemElement (CIMCORE)
     |  |
     |  +--LogicalElement (CIMCORE)
     |     |
     |     +--Service (CIMCORE)
     |     |  |
     |     |  +--DropThresholdCalculationService
     |     |
     |     +--FilterEntryBase [PCIME]
     |     |  |
     |     |  +--IPHeaderFilter [PCIME]
     |     |  |
     |     |  +--8021Filter [PCIME]
     |     |  |
     |     |  +--PreambleFilter
     |     |
     |     +--FilterList [PCIME]
     |     |
     |     +--ServiceAccessPoint (CIMCORE)
     |        |
     |        +--ProtocolEndpoint
     |
     +--Collection (CIMCORE)
     |  |
     |  +--CollectionOfMSEs (CIMCORE)
     |     |
     |     +--BufferPool
     |
     +--SchedulingElement
        |
        +--AllocationSchedulingElement
        |
        +--WRRSchedulingElement
        |
        +--PrioritySchedulingElement
           |
           +--BoundedPrioritySchedulingElement
 
 
  Figure 9.  Class Inheritance Hierarchy
 
 
 
 
 
 
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 36]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   The inheritance hierarchy for the associations defined in this
   draft is shown in Figure 9.
 
  +--Dependency (CIMCORE)
  |  |
  |  +--ServiceSAPDependency (CIMCORE)
  |  |  |
  |  |  +--IngressConditioningServiceOnEndpoint
  |  |  |
  |  |  +--EgressConditioningServiceOnEndpoint
  |  |
  |  +--HeadTailDropQueueBinding
  |  |
  |  +--CalculationBasedOnQueue
  |  |
  |  +--ProvidesServiceToElement (CIMCORE)
  |  |  |
  |  |  +--ServiceServiceDependency (CIMCORE)
  |  |     |
  |  |     +--CalculationServiceForDropper
  |  |
  |  +--QueueAllocation
  |  |
  |  +--ClassifierElementUsesFilterList
  |
  +--AFRelatedServices
  |
  +--NextService
  |  |
  |  +--NextServiceAfterClassifierElement
  |  |
  |  +--NextScheduler
  |    |
  |    +--FailNextScheduler
  |
  +--NextServiceAfterMeter
  |
  +--QueueToSchedule
  |
  +--SchedulingServiceToSchedule
 
 
  Figure 10.  Association Class Inheritance Hierarchy
 
 
 
 
 
 
 
 
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 37]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   The inheritance hierarchy for the aggregations defined in this
   draft is shown in Figure 10.
 
  +--MemberOfCollection (CIMCORE)
  |  |
  |  +--CollectedBufferPool
  |
  +--Component (CIMCORE)
  |  |
  |  +--ServiceComponent (CIMCORE)
  |  |  |
  |  |  +--QoSSubService
  |  |  |
  |  |  +--QoSConditioningSubService
  |  |  |
  |  |  +--ClassifierElementInClassifierService
  |  |
  |  +--EntriesInFilterList [PCIME]
  |
  +--ElementInSchedulingService
 
 
   Figure 11.  Aggregation Class Inheritance Hierarchy
 
 4.3. Class Definitions
 
   This section presents the classes and properties that make up the
   Information Model for describing QoS-related functionality in
   network devices, including hosts.  These definitions are derived
   from definitions in the CIM Core model [CIM].  Only the QoS-
   related classes are defined in this draft.  However, other
   classes drawn from the CIM Core model, as well as from [PCIME],
   are described briefly.  The reader is encouraged to look at [CIM]
   and at [PCIME] for further information.  Associations and
   aggregations are defined in Section 4.4.
 
 4.3.1. The Abstract Class ManagedElement
 
   This is an abstract class defined in the Core Model of CIM.  It
   is the root of the entire class inheritance hierarchy in CIM.
   Among the associations that refer to it are two that are
   subclassed in this document: Dependency and MemberOfCollection,
   which is an aggregation.  ManagedElement's properties are Caption
   and Description.  Both are free-form strings to describe an
   instantiated object.  Please refer to [CIM] for the full
   definition of this class.
 
 4.3.2. The Abstract Class ManagedSystemElement
 
   This is an abstract class defined in the Core Model of CIM; it is
   a subclass of ManagedElement.  ManagedSystemElement serves as the
   base class for the PhysicalElement and LogicalElement class
   hierarchies.  LogicalElement, in turn, is the base class for a
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 38]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   number of important CIM hierarchies, including System.  Any
   distinguishable component of a System is a candidate for
   inclusion in this class hierarchy, including physical components
   (e.g., chips and cards) and logical components (e.g., software
   components, services, and other objects).
 
   None of the associations in which this class participates is used
   directly in the QoS device state model.  However, the aggregation
   Component, which relates one ManagedSystemElement to another, is
   the base class for the two aggregations that form the core of the
   QoS device state model: QoSSubService and
   QoSConditioningSubService.  Similarly, the association
   ProvidesServiceToElement, which relates a ManagedSystemElement to
   a Service, is the base class for the model's
   CalculationServiceForDropper association.
 
   Please refer to [CIM] for the full definition of this class.
 
 4.3.3. The Abstract Class LogicalElement
 
   This is an abstract class defined in the Core Model of CIM.  It
   is a subclass of the ManagedSystemElement class, and is the base
   class for all logical components of a managed System, such as
   Files, Processes, or system capabilities in the form of Logical
   Devices and Services.  None of the associations in which this
   class participates is relevant to the QoS device state model.
   Please refer to [CIM] for the full definition of this class.
 
 4.3.4. The Abstract Class Service
 
   This is an abstract class defined in the Core Model of CIM.  It
   is a subclass of the LogicalElement class, and is the base class
   for all objects that represent a "service" or functionality in a
   System.  A Service is a general-purpose object that is used to
   configure and manage the implementation of functionality.  As
   noted above in section 4.3.2, this class participates in the
   ProvidesServiceToElement association.  Please refer to [CIM] for
   the full definition of this class.
 
 4.3.5. The Class ConditioningService
 
   This is a concrete subclass of the CIM Core class Service; it
   represents the ability to define how traffic is conditioned in
   the data-forwarding path of a device.  The subclasses of
   ConditioningService define the particular types of conditioning
   that are done.  Six fundamental types of conditioning are defined
   in this draft.  These are the services performed by a classifier,
   a meter, a marker, a dropper, a queue, and a scheduler.  Other,
   more sophisticated types of conditioning may be defined in future
   documents.
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 39]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   ConditioningService is a concrete class because at the time it
   was defined in CIM, its superclass was concrete. While this class
   can be instantiated, an instance of it would not accomplish
   anything, because the nature of the conditioning, and the
   parameters that control it, are specified only in the subclasses
   of ConditioningService.
 
   Two associations in which ConditioningService participates are
   critical to its usage in QoS - QoSConditioningSubService and
   NextService.  QoSConditioningSubService aggregates
   ConditioningServices into a particular QoS service (such as AF),
   to describe the specific conditioning functionality that
   underlies that QoS service in a particular device.  NextService
   indicates the subsequent conditioning service(s) for different
   traffic streams.
 
   The class definition is as follows:
 
          NAME                ConditioningService
          DESCRIPTION         A concrete class to define how traffic
                              is conditioned in the data forwarding
                              path of a host or network device.
          DERIVED FROM        Service
          TYPE                Concrete
          PROPERTIES          (none)
 
 4.3.6. The Class ClassifierService
 
   The concept of a Classifier comes from [DSMODEL].
   ClassifierService is a concrete class that represents a logical
   entity in an ingress or egress interface of a device, that takes
   a single input stream, and sorts it into one or more output
   streams.  The sorting is done by a set of filters that select
   packets based on the packet contents, or possibly based on other
   attributes associated with the packet.  Each output stream is the
   result of matching a particular filter.
 
   The representation of classifiers in QDDIM is closely related to
   that presented in [DSMIB] and [DSMODEL].  Rather than being
   linked directly to its FilterLists, a classifier is modeled here
   as an aggregation of ClassifierElements.  Each of these
   ClassifierElements is then linked to a single FilterList, by the
   association ClassifierElementUsesFilterList.
 
   A Classifier is modeled as a ConditioningService so that it can
   be aggregated into a QoSService (using the
   QoSConditioningSubService aggregation), and can use the
   NextService association to identify the subsequent
   ConditioningServices for different traffic streams.
 
   ClassifierService is designed to allow hierarchical
   classification. When hierarchical classification is used, a
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 40]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   ClassifierElement may point to another ClassifierService. When
   used for this purpose, the ClassifierElement must not use the
   ClassifierElementUsesFilterList association.
 
   The class definition is as follows:
 
       NAME                ClassifierService
       DESCRIPTION         A concrete class describing how an input
                           traffic stream is sorted into multiple
                           output streams using one or more
                           filters.
       DERIVED FROM        ConditioningService
       TYPE                Concrete
       PROPERTIES          (none)
 
 
 4.3.7. The Class ClassifierElement
 
   The concept of a ClassifierElement comes from [DSMIB].  This
   concrete class represents the linkage, within a single
   ClassifierService, between a FilterList that specifies a set of
   criteria for selecting packets from the stream of packets coming
   into the ClassifierService, and the next ConditioningService to
   which the selected packets go after they leave the
   ClassifierService.  ClassifierElement has no properties of its
   own.  It is present to serve as the anchor for an aggregation
   with its classifier, and for associations with its FilterList and
   its next ConditioningService.
 
   When a ClassifierElement is associated with a ClassifierService
   through the NextServiceAfterClassifierElement association, the
   ClassifierElement may not use the ClassifierElementUsesFilterList
   association. Further, when a ClassifierElement is associated with
   a ClassifierService as described above, the order of processing
   of the associated ClassifierService is a function of the
   ClassifierOrder property of the
   ClassifierElementInClassifierService aggregation. For example,
   lets assume the following:
 
   1.  ClassifierService (C1) aggregates ClassifierElements (E1),
       (E2) and (E3), with relative ClassifierOrder values of 1, 2,
       and 3.
 
   2.  ClassifierElements (E1) and (E3) associations to FilterLists
       (F1) and (F3) respectively using the
       ClassifierElementUsesFilterList association.
 
   3.  (E1) & (E3) are associated with Meters (M1) and (M3) through
       their respective NextServiceAfterClassifierElement
       associations.
 
   4.  (E2) is associated with ClassifierService (C2) through its
       NextServiceAfterClassifierElement association.
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 41]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   5.  ClassifierService (C2) aggregates ClassifierElements (E4) and
       (E5) with relative ClassifierOrder values of 1 and 2.
 
   6.  ClassifierElements (E4) and (E5) have associations to
       FilterLists (F4) and (F5) respectively using the
       ClassifierElementUsesFilterList association.
 
   In this example, packet processing would match FilterLists in the
   order of (F1), (F4), (F5), and (F3).
 
   The class definition is as follows:
 
       NAME                ClassifierElement
       DESCRIPTION         A concrete class representing
                           the process by which a classifier
                           uses a filter to select packets
                           to forward to a specific next
                           conditioning service.
       DERIVED FROM        ClassifierService
       TYPE                Concrete
       PROPERTIES          (none)
 
 
 
 4.3.8. The Class MeterService
 
   This is a concrete class that represents the metering of network
   traffic.  Metering is the function of monitoring the arrival
   times of packets of a traffic stream, and determining the level
   of conformance of each packet with respect to a pre-established
   traffic profile.  A meter has the ability to invoke different
   ConditioningServices for conforming and non-conforming traffic.
   Traffic leaving a meter may be further conditioned (e.g., dropped
   or queued) by routing the packet to another conditioning element.
   Please see [DSMODEL] for more information on metering.
 
   This class is the base class for defining different types of
   meters.  As such, it contains common properties that all meter
   subclasses share.  It is modeled as a ConditioningService so that
   it can be aggregated into a QoSService (using the
   QoSConditioningSubService association), to indicate that its
   functionality underlies that QoS service.  MeterService also
   participates in the NextServiceAfterMeter association, to
   identify the subsequent ConditioningServices for conforming and
   non-conforming traffic.
 
   The class definition is as follows:
 
       NAME                MeterService
       DESCRIPTION         A concrete class describing the
                           monitoring of traffic with respect to a
                           pre-established traffic profile.
       DERIVED FROM        ConditioningService
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 42]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
       TYPE                Concrete
       PROPERTIES          MeterType, OtherMeterType,
                           ConformanceLevels
 
 
   Note: The MeterType property and the MeterService subclasses
   provide similar information.  The MeterType property is defined
   for query purposes and for future expansion.  It is possible that
   not all MeterServices will require a subclass to define them.  In
   these cases, MeterService will be instantiated directly, and the
   MeterType property will provide the only way of identifying the
   type of the meter.
 
 4.3.8.1 The Property MeterType
 
   This property is an enumerated 16-bit unsigned integer that is
   used to specify the particular type of meter represented by an
   instance of MeterService. The following enumeration values are
   defined:
 
      1 - Other
      2 - Average Rate Meter
      3 - Exponentially Weighted Moving Average Meter
      4 - Token Bucket Meter
 
 
   Note: if the value of MeterType is not one of these four values,
   it SHOULD be interpreted as if it had the value '1' (Other).
 
 4.3.8.2 The Property OtherMeterType
 
   This is a string property that defines a vendor-specific
   description of a type of meter.  It is used when the value of the
   MeterType property in the instance is equal to 1.
 
 4.3.8.3 The Property ConformanceLevels
 
   This property is a 16-bit unsigned integer.  It indicates the
   number of conformance levels supported by the meter.  For
   example, when only "in profile" versus "out of profile" metering
   is supported, ConformanceLevels is equal to 2.
 
 4.3.9. The Class AverageRateMeterService
 
   This is a concrete subclass of MeterService that represents a
   simple meter, called an Average Rate Meter.  This type of meter
   measures the average rate at which packets are submitted to it
   over a specified time.  Packets are defined as conformant if
   their average arrival rate does not exceed the specified
   measuring rate of the meter.  Any packet that causes the
   specified measuring rate to be exceeded is defined to be non-
   conforming.  For more information, please see [DSMODEL].
 
   The class definition is as follows:
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 43]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
       NAME                AverageRateMeterService
       DESCRIPTION         A concrete class classifying traffic as
                           either conforming or non-conforming,
                           depending on whether the arrival of a
                           packet causes the average arrival rate
                           to exceed a pre-determined value.
       DERIVED FROM        MeterService
       TYPE                Concrete
       PROPERTIES          AverageRate, DeltaInterval
 
 
 4.3.9.1 The Property AverageRate
 
   This is an unsigned 32-bit integer that defines the rate used to
   determine whether admitted packets are in conformance or not.
   The value is specified in kilobits per second.
 
 4.3.9.2 The Property DeltaInterval
 
   This is an unsigned 64-bit integer that defines the time period
   over which the average measurement should be taken.  The value is
   specified in microseconds.
 
 4.3.10. The Class EWMAMeterService
 
   This is a concrete subclass of the MeterService class that
   represents an exponentially weighted moving average meter.  This
   meter is a simple low-pass filter that measures the rate of
   incoming packets over a small, fixed sampling interval.  Any
   admitted packet that pushes the average rate over a pre-defined
   limit is defined to be non-conforming.  Please see [DSMODEL] for
   more information.
 
   The class definition is as follows:
 
       NAME                EWMAMeterService
       DESCRIPTION         A concrete class classifying admitted
                           traffic as either conforming or non-
                           conforming, depending on whether the
                           arrival of a packet causes the average
                           arrival rate in a small fixed
                           sampling interval to exceed a
                           pre-determined value or not.
       DERIVED FROM        MeterService
       TYPE                Concrete
       PROPERTIES          AverageRate, DeltaInterval, Gain
 
 
 4.3.10.1 The Property AverageRate
 
   This property is an unsigned 32-bit integer that defines the
   average rate against which the sampled arrival rate of packets
   should be measured.  Any packet that causes the sampled rate to
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 44]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   exceed this rate is deemed non-conforming.  The value is
   specified in kilobits per second.
 
 4.3.10.2 The Property DeltaInterval
 
   This property is an unsigned 64-bit integer that defines the
   sampling interval used to measure the arrival rate.  The
   calculated rate is averaged over this interval and checked
   against the AverageRate property.  All packets whose computed
   average arrival rate is less than the AverageRate are deemed
   conforming.
 
   The value is specified in microseconds.
 
 4.3.10.3 The Property Gain
 
   This property is an unsigned 32-bit integer representing the
   reciprocal of the time constant (e.g., frequency response) of
   what is essentially a simple low-pass filter.  For example, the
   value 64 for this property represents a time constant value of
   1/64.
 
 4.3.11. The Class TokenBucketMeterService
 
   This is a concrete subclass of the MeterService class that
   represents the metering of network traffic using a token bucket
   meter.  Two types of token bucket meters are defined using this
   class - a simple, two-parameter bucket meter, and a multi-stage
   meter.
 
   A simple token bucket usually has two parameters, an average
   token rate and a burst size, and has two conformance levels:
   "conforming" and "non-conforming".  This class also defines an
   excess burst size, which enables the meter to have three
   conformance levels ("conforming", "partially conforming", and
   "non-conforming").  In this case, packets that exceed the excess
   burst size are deemed non-conforming, while packets that exceed
   the smaller burst size but are less than the excess burst size
   are deemed partially conforming.  Operation of these meters is
   described in [DSMODEL].
 
   The class definition is as follows:
 
       NAME                TokenBucketMeterService
       DESCRIPTION         A concrete class classifying admitted
                           traffic with respect to a token bucket.
                           Either two or three levels of
                           conformance can be defined.
       DERIVED FROM        MeterService
       TYPE                Concrete
       PROPERTIES          AverageRate, PeakRate,
                           BurstSize, ExcessBurstSize
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 45]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
 
 4.3.11.1 The Property AverageRate
 
   This property is an unsigned 32-bit integer that specifies the
   committed rate of the meter.  The value is expressed in kilobits
   per second.
 
 4.3.11.2 The Property PeakRate
 
   This property is an unsigned 32-bit integer that specifies the
   peak rate of the meter.  The value is expressed in kilobits per
   second.
 
 4.3.11.3 The Property BurstSize
 
   This property is an unsigned 32-bit integer that specifies the
   maximum number of tokens available for the committed rate
   (specified by the AverageRate property).  The value is expressed
   in kilobytes.
 
 4.3.11.4 The Property ExcessBurstSize
 
   This property is am unsigned 32-bit integer that specifies the
   maximum number of tokens available for the peak rate (specified
   by the PeakRate property).  The value is expressed in kilobytes.
 
 4.3.12. The Class MarkerService
 
   This is a concrete class that represents the general process of
   marking some field in a network packet with some value.
   Subclasses of MarkerService identify particular fields to be
   marked, and introduce properties to represent the values to be
   used in marking these fields.  Markers are usually invoked as a
   result of a preceding classifier match.  Operation of markers of
   various types is described in [DSMODEL].
 
   MarkerService is a concrete class because at the time it was
   defined in CIM, its superclass was concrete.  While this class
   can be instantiated, an instance of it would not accomplish
   anything, because both the field to be marked and the value to be
   used to mark it are specified only in subclasses of
   MarkerService.
 
   MarkerService is modeled as a ConditioningService so that it can
   be aggregated into a QoSService (using the
   QoSConditioningSubService association) to indicate that its
   functionality underlies that QoS service.  It participates in the
   NextService association to identify the subsequent
   ConditioningService that acts on traffic after it has been marked
   by the marker.
 
   The class definition is as follows:
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 46]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
       NAME                MarkerService
       DESCRIPTION         A concrete class representing the
                           general process of marking a selected
                           field in a packet with a specified
                           value.  Packets are marked in order
                           to control the conditioning that
                           they will subsequently receive.
       DERIVED FROM        ConditioningService
       TYPE                Concrete
       PROPERTIES          (none)
 
 
 4.3.13. The Class PreambleMarkerService
 
   This is a concrete class that models the storing of traffic-
   conditioning results in a packet preamble.  See Section 3.8.3 for
   a discussion of how, and why, QDDIM models the capability to
   store these results in a packet preamble.  An instance of
   PreambleMarkerService appends to a packet preamble a two-part
   string of the form "<type>,<value>".  Section 3.8.3 provides a
   list of the <type> strings defined by QDDIM.  Implementations may
   support other <type>'s in addition to these.
 
   The class definition is as follows:
 
       NAME                PreambleMarkerService
       DESCRIPTION         A concrete class representing the saving
                           of traffic-conditioning results in a
                           packet preamble.
       DERIVED FROM        MarkerService
       TYPE                Concrete
       PROPERTIES          FilterItemList[ ]
 
 
 4.3.13.1 The Multi-valued Property FilterItemList
 
 This property is an ordered list of strings, where each string has
 the format "<type>,<value>".  See Section 3.8.3 for a list of
 <type>'s defined in QDDIM, and the nature of the associated <value>
 for each of these types.
 
 4.3.14. The Class ToSMarkerService
 
   This is a concrete class that represents the marking of the ToS
   field in the IPv4 packet header [R791].  Following common
   practice, the value to be written into the field is represented
   as an unsigned 8-bit integer.
 
   The class definition is as follows:
 
       NAME                ToSMarkerService
       DESCRIPTION         A concrete class representing the
                           process of marking the type of service
                           (ToS) field in the IPv4 packet header
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 47]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
                           with a specified value.  Packets are
                           marked in order to control the
                           conditioning that they will subsequently
                           receive.
       DERIVED FROM        MarkerService
       TYPE                Concrete
       PROPERTIES          ToSValue
 
 
 
 4.3.14.1 The Property ToSValue
 
   This property is an unsigned 8-bit integer, representing a value
   to be used for marking the type of service (ToS) field in the
   IPv4 packet header.  The ToS field is defined to be a complete
   octet, so the range for this property is 0..255.  Some
   implementations, however, require that the lowest-order bit in
   the ToS field always be '0'.  Such an implementation is
   consequently unable to support an odd TosValue.
 
 4.3.15. The Class DSCPMarkerService
 
   This is a concrete class that represents the marking of the
   differentiated services codepoint (DSCP) within the DS field in
   the IPv4 and IPv6 packet headers, as defined in [R2474].
   Following common practice, the value to be written into the field
   is represented as an unsigned 8-bit integer.
 
   The class definition is as follows:
 
       NAME                DSCPMarkerService
       DESCRIPTION         A concrete class representing the
                           process of marking the DSCP field
                           in a packet with a specified
                           value.  Packets are marked in order
                           to control the conditioning that
                           they will subsequently receive.
       DERIVED FROM        MarkerService
       TYPE                Concrete
       PROPERTIES          DSCPValue
 
 
 
 4.3.15.1 The Property DSCPValue
 
   This property is an unsigned 8-bit integer, representing a value
   to be used for marking the DSCP within the DS field in an IPv4 or
   IPv6 packet header.  Since the DSCP consists of 6 bits, the
   values for this property are limited to the range 0..63.  When
   the DSCP is marked, the remaining two bit in the DS field are
   left unchanged.
 
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 48]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
 4.3.16. The Class 8021QMarkerService
 
   This is a concrete class that represents the marking of the user
   priority field defined in the IEEE 802.1Q specification
   [IEEE802Q].  Following common practice, the value to be written
   into the field is represented as an unsigned 8-bit integer.
 
 
   The class definition is as follows:
 
       NAME                8021QMarkerService
       DESCRIPTION         A concrete class representing the
                           process of marking the Priority
                           field in an 802.1Q-compliant frame
                           with a specified value.  Frames are
                           marked in order to control the
                           conditioning that they will
                           subsequently receive.
       DERIVED FROM        MarkerService
       TYPE                Concrete
       PROPERTIES          PriorityValue
 
 
 
 4.3.16.1 The Property PriorityValue
 
   This property is an unsigned 8-bit integer, representing a value
   to be used for marking the Priority field in the 802.1Q header.
   Since the Priority field consists of 3 bits, the values for this
   property are limited to the range 0..7.  When the Priority field
   is marked, the remaining bits in its octet are left unchanged.
 
 4.3.17. The Class DropperService
 
   This is a concrete class that represents the ability to
   selectively drop network traffic, or to invoke another
   ConditioningService for further processing of traffic that is not
   dropped.  This is the base class for different types of droppers.
   Droppers are distinguished by the algorithm that they use to drop
   traffic.  Please see [DSMODEL] for more information about the
   various types of droppers.  Note that this class encompasses both
   Absolute Droppers and Algorithmic Droppers from [DSMODEL].
 
   DropperService is modeled as a ConditioningService so that it can
   be aggregated into a QoSService (using the
   QoSConditioningSubService association) to indicate that its
   functionality underlies that QoS service.  It participates in the
   NextService association to identify the subsequent
   ConditioningService that acts on any remaining traffic that is
   not dropped.
 
   NextService has special semantics for droppers, in addition to
   the general "what happens next" semantics that apply to all
   ConditioningServices.  The queue(s) from which a particular
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 49]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   dropper drops packets are identified by following chain(s) of
   NextService associations "rightwards" from the dropper until they
   reach a queue.
 
   The class definition is as follows:
 
       NAME                DropperService
       DESCRIPTION         A concrete base class describing the
                           common characteristics of droppers.
       DERIVED FROM        ConditioningService
       TYPE                Concrete
       PROPERTIES          DropperType, OtherDropperType, DropFrom
 
 
   Note: The DropperType property and the DropperService subclasses
   provide similar information.  The DropperType property is defined
   for query purposes, as well as for those cases where a subclass
   of DropperService is not needed to model a particular type of
   dropper.  For example, the Absolute Dropper defined in [DSMODEL]
   is modeled as an instance of the DropperService class with its
   DropperType set to '4' ("Absolute Dropper").
 
 4.3.17.1 The Property DropperType
 
   This is an enumerated 16-bit unsigned integer that defines the
   type of dropper.  Values include:
 
     1 - Other
     2 - Random
     3 - HeadTail
     4 - Absolute Dropper
 
   Note: if the value of DropperType is not one of these four
   values, it SHOULD be interpreted as if it had the value '1'
   (Other).
 
 4.3.17.2 The Property OtherDropperType
 
   This string property is used in conjunction with the DropperType
   property.  When the value of DropperType is '1' (i.e., Other),
   then the name of the type of dropper appears in this property.
 
 4.3.17.3 The Property DropFrom
 
   This is an unsigned 16-bit integer enumeration that indicates the
   point in the associated queue from which packets should be
   dropped.  Defined enumeration values are
 
     o  unknown(0)
     o  head(1)
     o  tail(2)
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 50]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   Note: if the value of DropFrom is '0' (unknown), or if it is not
   one of the three values listed here, then packets MAY be dropped
   from any location in the associated queue.
 
 4.3.18. The Class HeadTailDropperService
 
   This is a concrete class that represents the threshold
   information of a head or tail dropper.  The inherited property
   DropFrom indicates whether a particular instance of this class
   represents a head dropper or a tail dropper.
 
   A head dropper always examines the same queue from which it drops
   packets, and this queue is always related to the dropper as the
   following service in the NextService association.
 
   The class definition is as follows:
 
       NAME                HeadTailDropperService
       DESCRIPTION         A concrete class used to describe
                           a head or tail dropper.
       DERIVED FROM        DropperService
       TYPE                Concrete
       PROPERTIES          QueueThreshold
 
 
 4.3.18.1 The Property QueueThreshold
 
   This is an unsigned 32-bit integer that indicates the queue depth
   at which traffic will be dropped.  For a tail dropper, all newly
   arriving traffic is dropped.  For a head dropper, packets at the
   front of the queue are dropped to make room for new packets,
   which are added at the end.  The value is expressed in bytes.
 
 4.3.19. The Class REDDropperService
 
   This is a concrete class that represents the ability to drop
   network traffic using a Random Early Detection (RED) algorithm.
   This algorithm is described in [RED].  The purpose of a RED
   algorithm is to avoid congestion (as opposed to managing
   congestion).  Instead of waiting for the queues to fill up, and
   then dropping large numbers of packets, RED works by monitoring
   the average queue depth.  When the queue depth exceeds a minimum
   threshold, packets are randomly discarded.  These discards cause
   TCP to slow its transmission rate for those connections that
   experienced the packet discards.  Other TCP connections are not
   affected by these discards.  Please see [DSMODEL] for more
   information about a dropper.
 
   A RED dropper always drops packets from a single queue, which is
   related to the dropper as the following service in the
   NextService association.  The queue(s) examined by the drop
   algorithm are found by following the CalculationServiceForDropper
   association to find the dropper's
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 51]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
   DropThresholdCalculationService, and then following the
   CalculationBasedOnQueue association(s) to find the queue(s) being
   watched.
 
 
   The class definition is as follows:
 
       NAME                REDDropperService
       DESCRIPTION         A concrete class used to describe
                           dropping using the RED algorithm (or
                           one of its variants).
       DERIVED FROM        DropperService
       TYPE                Concrete
       PROPERTIES          MinQueueThreshold, MaxQueueThreshold,
                           ThresholdUnits, StartProbability,
                           StopProbability
 
 
   NOTE:  In [DSMIB], there is a single diffServRandomDropTable,
   which represents the general category of random dropping.  (RED
   is one type of random dropping, but there are also types of
   random dropping distinct from RED.)  The REDDropperService class
   corresponds to the columns in the table that apply to the RED
   algorithm in particular.
 
 4.3.19.1 The Property MinQueueThreshold
 
   This is an unsigned 32-bit integer that defines the minimum
   average queue depth at which packets are subject to being
   dropped.  The units are identified by the ThresholdUnits
   property.  The slope of the drop probability function is
   described by the Start/StopProbability properties.
 
 4.3.19.2 The Property MaxQueueThreshold
 
   This is an unsigned 32-bit integer that defines the maximum
   average queue length at which packets are subject to always being
   dropped, regardless of the dropping algorithm and probabilities
   being used.  The units are identified by the ThresholdUnits
   property.
 
 4.3.19.3 The Property ThresholdUnits
 
   This is an unsigned 16-bit integer enumeration that identifies
   the units for the MinQueueThreshold and MaxQueueThreshold
   properties.  Defined enumeration values are
 
      o    bytes(1)
      o    packets(2)
 
   Note: if the value of ThresholdUnits is not one of these two
   values, it SHOULD be interpreted as if it had the value '1'
   (bytes).
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 52]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
 4.3.19.4 The Property StartProbability
 
   This is an unsigned 32-bit integer; in conjunction with the
   StopProbability property, it defines the slope of the drop
   probability function.  This function governs the rate at which
   packets are subject to being dropped, as a function of the queue
   length.
 
   This property expresses a drop probability in drops per thousand
   packets.  For example, the value 100 indicates a drop probability
   of 100 per 1000 packets, that is, 10%.  Min and max values are 0
   to 1000.
 
 4.3.19.5 The Property StopProbability
 
   This is an unsigned 32-bit integer; in conjunction with the
   StartProbability property, it defines the slope of the drop
   probability function.  This function governs the rate at which
   packets are subject to being dropped, as a function of the queue
   length.
 
   This property expresses a drop probability in drops per thousand
   packets.  For example, the value 100 indicates a drop probability
   of 100 per 1000 packets, that is, 10%.  Min and max values are 0
   to 1000.
 
 4.3.20. The Class QueuingService
 
   This is a concrete class that represents the ability to queue
   network traffic, and to specify the characteristics for
   determining long-term congestion.  Please see [DSMODEL] for more
   information about queuing functionality.
 
   QueuingService is modeled as a ConditioningService so that it can
   be aggregated into a QoSService (using the
   QoSConditioningSubService association) to indicate that its
   functionality underlies that QoS service.
 
   The class definition is as follows:
 
       NAME                QueuingService
       DESCRIPTION         A concrete class describing the ability
                           to queue network traffic and to specify
                           the characteristics for determining
                           long-term congestion.
       DERIVED FROM        ConditioningService
       TYPE                Concrete
       PROPERTIES          CurrentQueueDepth, DepthUnits
 
 
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 53]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
 4.3.20.1 The Property CurrentQueueDepth
 
   This is an unsigned 32-bit integer, which functions as a (read-
   only) gauge representing the current depth of this one queue.
   This value may be important in diagnosing unexpected behavior by
   a DropThresholdCalculationService.
 
 4.3.20.2 The Property DepthUnits
 
   This is an unsigned 16-bit integer enumeration that identifies
   the units for the CurrentQueueDepth property.  Defined
   enumeration values are
 
      o    bytes(1)
      o    packets(2)
 
   Note: if the value of DepthUnits is not one of these two values,
   it SHOULD be interpreted as if it had the value '1' (bytes).
 
 4.3.21. The Class PacketSchedulingService
 
   This is a concrete class that represents a scheduling service,
   which is a process that determines when a queued packet should be
   removed from a queue and sent to an output interface.  Note that
   output interfaces can be physical network interfaces or
   interfaces to components internal to systems, such as crossbars
   or back planes.  In either case, if multiple queues are involved,
   schedulers are used to provide access to the interface.
 
   Each instance of a PacketSchedulingService describes a scheduler
   from the perspective of the queues that it is servicing.  Please
   see [DSMODEL] for more information about a scheduler.
 
   PacketSchedulingService is modeled as a ConditioningService so
   that it can be aggregated into a QoSService (using the
   QoSConditioningSubService association) to indicate that its
   functionality underlies that QoS service.  It participates in the
   NextService association to identify the subsequent
   ConditioningService, if any, that acts on traffic after it has
   been processed by the scheduler.
 
   The class definition is as follows:
 
       NAME                PacketSchedulingService
       DESCRIPTION         A concrete class used to determine when
                           a packet should be removed from a
                           queue and sent to an output interface.
       DERIVED FROM        ConditioningService
       TYPE                Concrete
       PROPERTIES          SchedulerType, OtherSchedulerType
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 54]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
 4.3.21.1 The Property SchedulerType
 
   This property is an enumerated 16-bit unsigned integer, and
   defines the type of scheduler.  Values are:
 
      1 - Other
      2 - FIFO
      3 - Priority
      4 - Allocation
      5 - Bounded Priority
      6 - Weighted Round Robin Packet
 
 
   Note: if the value of SchedulerType is not one of these six
   values, it SHOULD be interpreted as if it had the value '2'
   (FIFO).
 
 4.3.21.2 The Property OtherSchedulerType
 
   This property is used in conjunction with the SchedulerType
   property.  When the value of SchedulerType is 1 (i.e., Other),
   then the type of scheduler is specified in this property.
 
 4.3.22. The Class NonWorkConservingSchedulingService
 
   This class does not add any properties beyond those it inherits
   from its superclass, PacketSchedulingService.  It does, however,
   participate in one additional association, FailNextScheduler.
 
   The class definition is as follows:
 
       NAME                NonWorkConservingSchedulingService
       DESCRIPTION         A concrete class representing a
                           scheduler that is capable of operating
                           in a non-work conserving manner.
       DERIVED FROM        PacketSchedulingService
       TYPE                Concrete
       PROPERTIES          (none)
 
 
 
 4.3.23. The Class QoSService
 
   This is a concrete class that represents the ability to
   conceptualize a QoS service as a set of coordinated sub-services.
   This enables the network administrator to map business rules to
   the network, and the network designer to engineer the network
   such that it can provide different functions for different
   traffic streams.
 
   This class has two main purposes.  First, it serves as a common
   base class for defining the various sub-services needed to build
   higher-level QoS services.  Second, it serves as a way to
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 55]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   consolidate the relationships between different types of QoS
   services and different types of ConditioningServices.
 
   For example, Gold Service may be defined as a QoSService which
   aggregates two QoSServices together.  Each of these QoSServices
   could be a DiffServService, one representing the servicing of
   very high demand packets (represented simply as a
   DiffServService), and one representing the service given to most
   of the packets, represented as an AFService.  The high demand
   DiffServService instance will then use the
   QoSConditioningSubService aggregation to aggregate together the
   necessary classifiers to indicate which traffic it applies to,
   and the appropriate meters for contract limits, the marker to
   mark the EF PHB in the packets, and the queuing-related
   conditioning services.  The AFService instance will also use the
   QoSConditioningSubService aggregation, to aggregate its
   classifiers and meters, the several markers used to mark the
   different AF PHBs in the packets, and the queuing-related
   conditioning services needed to deliver the packet treatment.
 
   QoSService is modeled as a type of Service, which is used as the
   anchor point for defining a set of sub-services that implement
   the desired conditioning characteristics for different types of
   flows.  It will direct the specific type of ConditioningServices
   to be used in order to implement this service.
 
   The class definition is as follows:
 
       NAME                QoSService
       DESCRIPTION         A concrete class used to represent a QoS
                           service or set of services, as defined
                           by a network administrator.
       DERIVED FROM        Service
       TYPE                Concrete
       PROPERTIES          (none)
 
 
 4.3.24. The Class DiffServService
 
   This is a concrete class representing the use of standard or
   custom DiffServ services to implement a (higher-level) QoS
   service.  Note that the DiffServService may be just one of a set
   of coordinated QoSSubServices that together implement a higher-
   level QoS service.
 
   DiffServService is modeled as a subclass of QoSService.  This
   enables it to be related to a higher-level QoS service via
   QoSSubService, as well as to specific ConditioningServices (e.g.,
   metering, dropping, queuing, and others) via
   QoSConditioningSubService.
 
   The class definition is as follows:
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 56]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
       NAME                DiffServService
       DESCRIPTION         A concrete class used to represent a
                           DiffServ service associated with a
                           particular Per Hop Behavior.
       DERIVED FROM        QoSService
       TYPE                Concrete
       PROPERTIES          PHBID
 
 
 4.3.24.1 The Property PHBID
 
   This property is a 16-bit unsigned integer, which identifies a
   particular per hop behavior, or family of per hop behaviors.  The
   value here is a Per Hop Behavior Identification Code, as defined
   in [R3140].  Note that as defined, these identification codes use
   the default, recommended, code points for PHBs as part of their
   structure.  These values may well be different from the actual
   value used in the marker, as the marked value is a domain-
   dependent value.  The ability to indicate the PHB Identification
   Code associated with a service is helpful for tying the QoS
   Service to reference documents, and for inter-domain coordination
   and operation.
 
 4.3.25. The Class AFService
 
   This is a concrete class that represents a specialization of the
   general concept of forwarding network traffic, by adding specific
   semantics that characterize the operation of the Assured
   Forwarding (AF) Service ([R2597]).
 
   [R2597] defines four different AF classes, to represent four
   different treatments of traffic.  A different amount of
   forwarding resources, such as buffer space and bandwidth, are
   allocated to each AF class.  Within each AF class, IP packets are
   marked with one of three possible drop precedence values.  The
   drop precedence of a packet determines the relative importance of
   that packet compared to other packets within the same AF class,
   if congestion occurs.  A congested interface will try to avoid
   dropping packets marked with a lower drop precedence value, by
   instead discarding packets marked with a higher drop precedence
   value.
 
   Note that [R2597] defines 12 DSCPs that together represent the AF
   Per Hop Behavior (PHB) group.  Implementations are free to extend
   this (e.g., add more classes and/or drop precedences).
 
   The AFService class is modeled as a specialization of
   DiffServService, which is in turn a specialization of QoSService.
   This enables it to be related to higher-level QoS services, as
   well as to lower-level conditioning sub-services (e.g.,
   classification, metering, dropping, queuing, and others).
 
   The class definition is as follows:
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 57]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
       NAME                AFService
       DESCRIPTION         A concrete class for describing the
                           common characteristics of differentiated
                           services that are used to affect
                           traffic forwarding, using the AF
                           PHB Group.
       DERIVED FROM        DiffServService
       TYPE                Concrete
       PROPERTIES          ClassNumber, DropperNumber
 
 
 4.3.25.1 The Property ClassNumber
 
   This property is an 8-bit unsigned integer that indicates the
   number of AF classes that this AF implementation uses.  Among the
   instances aggregated using the QoSConditioningSubService
   aggregation with an instance of AFService, one SHOULD find
   markers with as many distinct values as the ClassNumber of the
   AFService instance.
 
 4.3.25.2 The Property DropperNumber
 
   This property is an 8-bit unsigned integer that indicates the
   number of drop precedence values that this AF implementation
   uses.  The number of drop precedence values is the number PER AF
   CLASS.  The corresponding droppers will be found in the
   collection of conditioning services aggregated with the
   QoSConditioningSubService aggregation.
 
 4.3.26. The Class FlowService
 
   This class represents a service that supports a particular
   microflow.  The microflow is identified by the string-valued
   property FlowID.  In some implementations, an instance of this
   class corresponds to an entry in the implementation's flow table.
 
   The class definition is as follows:
 
       NAME                FlowService
       DESCRIPTION         A concrete class representing a
                           microflow.
       DERIVED FROM        QoSService
       TYPE                Concrete
       PROPERTIES          FlowID
 
 
 4.3.26.1 The Property FlowID
 
   This property is a string containing an identifier for a
   microflow.
 
 
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 58]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
 4.3.27. The Class DropThresholdCalculationService
 
   This class represents a logical entity that calculates an average
   queue depth for a queue, based on a smoothing weight and a
   sampling time interval.  It does this calculation on behalf of a
   RED dropper, to allow the dropper to make its decisions whether
   to drop packets based on a smoothed average queue depth for the
   queue.
 
   The class definition is as follows:
 
       NAME                DropThresholdCalculationService
       DESCRIPTION         A concrete class representing a logical
                           entity that calculates an average queue
                           depth for a queue, based on a smoothing
                           weight and a sampling time interval.
                           The latter are properties of this
                           Service, describing how it operates and
                           its necessary parameters.
       DERIVED FROM        Service
       TYPE                Concrete
       PROPERTIES          SmoothingWeight, TimeInterval
 
 
 4.3.27.1 The Property SmoothingWeight
 
   This property is a 32-bit unsigned integer, ranging between 0 and
   100,000 - specified in thousandths.  It defines the weighting of
   past history in affecting the calculation of the current average
   queue depth.  The current queue depth calculation uses the
   inverse of this value as its factor, and one minus that inverse
   as the factor for the historical average.  The calculation takes
   the form:
 
     average = (old_average*(1-inverse of SmoothingWeight))
 
          + (current_queue_depth*inverse of SmoothingWeight)
 
   Implementations may choose to limit the acceptable set of values
   to a specified set, such as powers of 2.
 
   Min and max values are 0 and 100000.
 
 4.3.27.2 The Property TimeInterval
 
   This property is a 32-bit unsigned integer, defining the number
   of nanoseconds between each calculation of average/smoothed queue
   depth.  If this property is not specified, the CalculationService
   may determine an appropriate interval.
 
 4.3.28. The Abstract Class FilterEntryBase
 
   FilterEntryBase is the abstract base class from which all filter
   entry classes are derived.  It serves as the endpoint for the
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 59]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   EntriesInFilterList aggregation, which groups filter entries into
   filter lists.  Its properties include CIM naming properties and
   an IsNegated boolean property (to easily "NOT" the match
   information specified in an instance of one of its subclasses).
 
   Because FilterEntryBase has general applicability, it is defined
   in [PCIME].  See [PCIME] for the definition of this class.
 
 4.3.29. The Class IPHeaderFilter
 
   This concrete class makes it possible to represent an entire IP
   header filter in a single object.  A property IpVersion
   identifies whether the IP addresses in an instance are IPv4 or
   IPv6 addresses.  (Since the source and destination IP addresses
   come from the same packet header, they will always be of the same
   type.)
 
   See [PCIME] for the definition of this class.
 
 4.3.30. The Class 8021Filter
 
   This concrete class allows 802.1.source and destination MAC
   addresses, as well as the 802.1 protocol ID, priority, and VLAN
   identifier fields, to be expressed in a single object
 
 See [PCIME] for the definition of this class.
 
 4.3.31. The Class PreambleFilter
 
   This is a concrete class that models classifying packets using
   traffic-conditioning results stored in a packet preamble by a
   PreambleMarkerService.  See Section 3.8.3 for a discussion of
   how, and why, QDDIM models the capability to store these results
   in a packet preamble.  An instance of PreambleFilter is used to
   select packets based on a two-part string identifying a specific
   result.  The logic for this match is "at least one."  That is, a
   packet with multiple results in its preamble matches a filter if
   at least one of these results matches the filter.
 
   The class definition is as follows:
 
       NAME                PreambleFilter
       DESCRIPTION         A concrete class representing criteria
                           for selecting packets based on prior
                           traffic-conditioning results stored in
                           a packet preamble.
       DERIVED FROM        FilterEntryBase
       TYPE                Concrete
       PROPERTIES          FilterItemList[ ]
 
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 60]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
 4.3.31.1 The Multi-valued Property FilterItemList
 
  This property is an ordered list of strings, where each string
  has the format "<type>,<value>".  See Section 3.8.3 for a list of
  <type>'s defined in QDDIM, and the nature of the associated
  <value> for each of these types.
 
   Note that there are two parallel terminologies for characterizing
   meter results.  The enumeration value "conforming(1)" is
   sometimes described as "in profile," and the value
   "nonConforming(3)" is sometimes described as "out of profile."
 
 4.3.32. The Class FilterList
 
   This is a concrete class that aggregates instances of (subclasses
   of) FilterEntryBase via the aggregation EntriesInFilterList.  It
   is possible to aggregate different types of filters into a single
   FilterList - for example, packet header filters (represented by
   the IPHeaderFilter class) and security filters (represented by
   subclasses of FilterEntryBase defined by IPsec).
 
   The aggregation property EntriesInFilterList.EntrySequence is
   always set to 0, to indicate that the aggregated filter entries
   are ANDed together to form a selector for a class of traffic.
 
   See [PCIME] for the definition of this class.
 
 4.3.33. The Abstract Class ServiceAccessPoint
 
   This is an abstract class defined in the Core Model of CIM.  It
   is a subclass of the LogicalElement class, and is the base class
   for all objects that manage access to CIM_Services.  It
   represents the management of utilizing or invoking a Service.
   Please refer to [CIM] for the full definition of this class.
 
 4.3.34. The Class ProtocolEndpoint
 
   This is a concrete class derived from ServiceAccessPoint, which
   describes a communication point from which the services of the
   network or the system's protocol stack may be accessed.
 
   The class definition is as follows:
 
       NAME                ProtocolEndpoint
       DESCRIPTION         A communication point from which
                           data may be sent or received.
       DERIVED FROM        ServiceAccessPoint
       TYPE                Concrete
       PROPERTIES          Name, NameFormat, ProtocolType,
                           OtherTypeDescription
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 61]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
 4.3.35. The Abstract Class Collection
 
   This is an abstract class defined in the Core Model of CIM.  It
   is the superclass for all classes that represent groupings or
   bags, and that carry no status or "state".  (The latter would be
   more correctly modeled as ManagedSystemElements.)  Please refer
   to [CIM] for the full definition of this class.
 
 4.3.36. The Abstract Class CollectionOfMSEs
 
   This is an abstract class defined in the Core Model of CIM.  It
   is a subclass of the Collection superclass, restricting the
   contents of the Collection to ManagedSystemElements.  Please
   refer to [CIM] for the full definition of this class.
 
 4.3.37. The Class BufferPool
 
   This is a concrete class that represents the collection of
   buffers used by a QueuingService.  (The association
   QueueAllocation represents this usage.)  The existence and
   management of individual buffers may be modeled in a future
   document.  At the current level of abstraction, modeling the
   existence of the BufferPool is necessary.  Long term, it is not
   sufficient.
 
   In implementations where there are multiple buffer sizes, an
   instance of BufferPool should be defined for each set of buffers
   with identical or similar sizes.  These instances of buffer pools
   can then be grouped together using the CollectedBuffersPool
   aggregation.
 
   Note that this class is derived from CollectionOfMSEs, and not
   from Forwarding or ConditioningService.  A BufferPool is only a
   collection of storage, and is NOT a Service.
 
   The class definition is as follows:
 
       NAME                BufferPool
       DESCRIPTION         A concrete class representing
                           a collection of buffers.
       DERIVED FROM        CollectionOfMSEs
       TYPE                Concrete
       PROPERTIES          Name, BufferSize, TotalBuffers,
                           AvailableBuffers, SharedBuffers
 
 
 4.3.37.1 The Property Name
 
   This property is a string with a maximum length of 256
   characters.  It is the common name or label by which the object
   is known.
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 62]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
 4.3.37.2 The Property BufferSize
 
   This property is a 16-bit unsigned integer, identifying the
   approximate number of bytes in each buffer in the buffer pool.
   An implementation will typically group buffers of roughly the
   same size together, to reduce the number of buffer pools it needs
   to manage.  This model does not specify the degree to which
   buffers in the same buffer pool may differ in size.
 
 4.3.37.3 The Property TotalBuffers
 
   This property is a 32-bit unsigned integer, reporting the total
   number of individual buffers in the pool.
 
 4.3.37.4 The Property AvailableBuffers
 
   This property is a 32-bit unsigned integer, reporting the number
   of buffers in the Pool that are currently not allocated to any
   instance of a QueuingService.  Buffers allocated to a
   QueuingService could either be in use (that is, currently contain
   packet data), or be allocated to a queue pending the arrival of
   new packet data.
 
 4.3.37.5 The Property SharedBuffers
 
   This property is a 32-bit unsigned integer, reporting the number
   of buffers in the Pool that have been simultaneously allocated to
   multiple instances of QueuingService.
 
 4.3.38. The Abstract Class SchedulingElement
 
   This is an abstract class that represents the configuration
   information that a PacketSchedulingService has for one of the
   elements that it is scheduling.  The scheduled element is either
   a QueuingService or another PacketSchedulingService.
 
   Among the subclasses of this class, some are defined in such a
   way that all of their instances are work conserving.  Other
   subclasses, however, may have instances that either are or are
   not work conserving.  In this class, the boolean property
   WorkConserving indicates whether an instance is or is not work
   conserving.  The range of values for WorkConserving is restricted
   to TRUE in the subclasses that are inherently work conserving,
   since instances of these classes cannot be anything other than
   work conserving.
 
   The class definition is as follows:
 
       NAME                SchedulingElement
       DESCRIPTION         An abstract class representing the
                           configuration information that a
                           PacketSchedulingService has for one of
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 63]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
                           the elements that it is scheduling.
       DERIVED FROM        ManagedElement
       TYPE                Abstract
       PROPERTIES          WorkConserving
 
 
 4.3.38.1 The Property WorkConserving
 
   This boolean property indicates whether the
   PacketSchedulingService tied to this instance by the
   ElementInSchedulingService aggregation is treating the input tied
   to this instance by the QueueToSchedule or
   SchedulingServiceToSchedule association in a work-conserving
   manner. Note that this property is writeable, indicating that an
   administrator can change the behavior of the SchedulingElement û
   but only for those elements that can operate in a non-work
   conserving mode.
 
 4.3.39. The Class AllocationSchedulingElement
 
   This class is a subclass of the abstract class SchedulingElement.
   It introduces five new properties to support bandwidth-based
   scheduling.  As is the case with all subclasses of
   SchedulingElement, the input associated with an instance of
   AllocationSchedulingElement is of one of two types: either a
   queue, or another scheduler.
 
   The class definition is as follows:
 
       NAME                AllocationSchedulingElement
       DESCRIPTION         A concrete class containing parameters
                           for controlling bandwidth-based
                           scheduling.
 
       DERIVED FROM        SchedulingElement
       TYPE                Concrete
       PROPERTIES          AllocationUnits, BandwidthAllocation,
                           BurstAllocation, CanShare,
                           WorkFlexible
 
 
 4.3.39.1 The Property AllocationUnits
 
   This property is a 16-bit unsigned integer enumeration that
   identifies the units in which the BandwidthAllocation and
   BurstAllocation properties are expressed.  The following values
   are defined:
 
     o bytes(1)
     o packets(2)
     o cells(3)       -- fixed-size, for example, ATM
 
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 64]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   Note: if the value of AllocationUnits is not one of these three
   values, it SHOULD be interpreted as if it had the value '1'
   (bytes).
 
 4.3.39.2 The Property BandwidthAllocation
 
   This property is a 32-bit unsigned integer that defines the
   number of units/second that should be allocated to the associated
   input.  The units are identified by the AllocationUnits property.
 
 4.3.39.3 The Property BurstAllocation
 
   This property is a 32-bit unsigned integer that specifies the
   amount of temporary or short-term bandwidth (in units per second)
   that can be allocated to an input, beyond the amount of bandwidth
   allocated through the BandwidthAllocation property.  If the
   maximum actual bandwidth allocation for the input were to be
   measured, it would be the sum of the BurstAllocation and the
   BandwidthAllocation properties.  The units are identified by the
   AllocationUnits property.
 
 4.3.39.4 The Property CanShare
 
   This is a boolean property that, if TRUE, enables unused
   bandwidth from the associated input to be allocated to other
   inputs serviced by the Scheduler.
 
 4.3.39.5 The Property WorkFlexible
 
   This is a boolean property that, if TRUE, indicates that the
   behavior of the scheduler relative to this input can be altered
   by changing the value of the inherited property WorkConserving.
 
 4.3.40. The Class WRRSchedulingElement
 
   This class is a subclass of the abstract class SchedulingElement.
   It introduces a new property WeightingFactor, to give some inputs
   a higher probability of being serviced than other inputs.  It
   also introduces a property Priority, to serve as a tiebreaker to
   be used when inputs have equal weighting factors.  As is the case
   with all subclasses of SchedulingElement, the input associated
   with an instance of WRRSchedulingElement is of one of two types:
   either a queue, or another scheduler.
 
   Because scheduling of this type is always work conserving, the
   inherited boolean property WorkConserving is restricted to the
   value TRUE in this class.
 
   The class definition is as follows:
 
       NAME              WRRSchedulingElement
       DESCRIPTION       This class specializes the
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 65]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
                         SchedulingElement class to add
                         a per-input weight.  This is used
                         by a weighted round robin packet
                         scheduler when it handles its
                         associated inputs.  It also adds a
                         second property to serve as a tie-breaker
                         in the case where multiple inputs have
                         been assigned the same weight.
       DERIVED FROM      SchedulingElement
       TYPE              Concrete
       PROPERTIES        WeightingFactor, Priority
 
 
 4.3.40.1 The Property WeightingFactor
 
   This property is a 32-bit unsigned integer, which defines the
   weighting factor that offers some inputs a higher probability of
   being serviced than other inputs.  This property represents this
   probability.  Its minimum value is 0, its maximum value is
   100000, and its units are thousandths.
 
 4.3.40.2 The Property Priority
 
   This property is a 16-bit unsigned integer, which serves as a
   tiebreaker, in the event that two or more inputs have equal
   weights.  A larger value represents a higher priority.
 
   While this condition may not occur in some implementations of a
   weighted round robin scheduler, many implementations require a
   priority to resolve an equal-weight condition.  In instances
   where this behavior is not necessary or is undesirable, this
   property may be left unspecified.
 
 4.3.41. The Class PrioritySchedulingElement
 
   This class is a subclass of the abstract class SchedulingElement.
   It indicates that a scheduler is taking packets from a set of
   inputs using the priority scheduling discipline.  As is the case
   with all subclasses of SchedulingElement, the input associated
   with an instance of PrioritySchedulingElement is of one of two
   types: either a queue, or another scheduler.  The property
   Priority in PrioritySchedulingElement represents the priority for
   an input, relative to the priorities of all the other inputs to
   which the scheduler that aggregates this
   PrioritySchedulingElement is associated.  Inputs to which the
   scheduler is related via other scheduling disciplines do not
   figure in this prioritization.
 
   Because scheduling of this type is always work conserving, the
   inherited boolean property WorkConserving is restricted to the
   value TRUE in this class.
 
   The class definition is as follows:
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 66]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
       NAME             PrioritySchedulingElement
       DESCRIPTION      A concrete class that specializes the
                        SchedulingElement class to add a
                        Priority property.  This property is
                        used by a SchedulingService that is doing
                        priority scheduling for a set of  inputs.
 
       DERIVED FROM     SchedulingElement
       TYPE             Concrete
       PROPERTIES       Priority
 
 
 4.3.41.1 The Property Priority
 
   This property is a 16-bit unsigned integer that indicates the
   priority level of a scheduler input relative to the other inputs
   serviced by this PacketSchedulingService.  A larger value
   represents a higher priority.
 
 4.3.42. The Class BoundedPrioritySchedulingElement
 
   This class is a subclass of the class PrioritySchedulingElement,
   which is itself derived from the abstract class
   SchedulingElement.  As is the case with all subclasses of
   SchedulingElement, the input associated with an instance of
   BoundedPrioritySchedulingElement is of one of two types: either a
   queue, or another scheduler.  BoundedPrioritySchedulingElement
   adds an upper bound (in kilobits per second) on how much traffic
   can be handled from an input.  This data is specific to that one
   input.  It is needed when bounded strict priority scheduling is
   performed.
 
   This class inherits from its superclass PrioritySchedulingElement
   the restriction of the inherited boolean property WorkConserving
   to the value TRUE.
 
   The class definition is as follows:
 
       NAME              BoundedPrioritySchedulingElement
       DESCRIPTION       This concrete class specializes the
                         PrioritySchedulingElement class to add
                         a BandwidthBound property.  This property
                         bounds the rate at which traffic from the
                         associated input can be handled.
 
       DERIVED FROM      PrioritySchedulingElement
       TYPE              Concrete
       PROPERTIES        BandwidthBound
 
 
 4.3.42.1 The Property BandwidthBound
 
   This property is a 32-bit unsigned integer that defines the upper
   limit on the amount of traffic that can be handled from the
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 67]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   input.  This is not a shaped upper bound, since bursts can occur.
   It is a strict bound, limiting the impact of the input.  The
   units are kilobits per second.
 
 4.4. Association Definitions
 
   This section details the QoS device datapath associations,
   including the aggregations, which were shown earlier in Figures 4
   and 5.  These associations are defined as classes in the
   Information Model.  Each of these classes has two properties
   referring to instances of the two classes that the association
   links.  Some of the association classes have additional
   properties as well.
 
 4.4.1. The Abstract Association Dependency
 
   This abstract association defines two object references (named
   Antecedent and Dependent) that establish general dependency
   relationships between different managed objects in the
   information model.  The Antecedent reference identifies the
   independent object in the association, while the Dependent
   reference identifies the entity that IS dependent.
 
   The association's cardinality is many to many.
 
   The association is defined in the Core Model of CIM.  Please
   refer to [CIM] for the full definition of this class.
 
 4.4.2. The Association ServiceSAPDependency
 
   This association defines two object references that establish a
   general dependency relationship between a Service object and a
   ServiceAccessPoint object.  This relationship indicates that the
   referenced Service uses the ServiceAccessPoint of ANOTHER
   Service.  The Service is the Dependent reference, relying on the
   ServiceAccessPoint to gain access to another Service.
 
   The association's cardinality is many to many.
 
   The association is defined in the Core Model of CIM.  Please
   refer to [CIM] for the full definition of this class.
 
 4.4.3. The Association IngressConditioningServiceOnEndpoint
 
   This association is derived from the association
   ServiceSAPDependency, and represents the binding, in the ingress
   direction, between a protocol endpoint and the first
   ConditioningService that processes packets received via that
   protocol endpoint.  Since there can only be one "first"
   ConditioningService for a protocol endpoint, the cardinality for
   the Dependent object reference is narrowed from 0..n to 0..1.
   Since, on the other hand, a single ConditioningService can be the
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 68]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   first to process packets received via multiple protocol
   endpoints, the cardinality of the Antecedent object reference
   remains 0..n.
 
   The class definition is as follows:
 
       NAME              IngressConditioningServiceOnEndpoint
       DESCRIPTION       An association that establishes a
                         dependency relationship between a protocol
                         endpoint and the first conditioning
                         service that processes traffic arriving
                         via that protocol endpoint.
       DERIVED FROM      ServiceSAPDependency
       ABSTRACT          False
       PROPERTIES        Antecedent[ref ProtocolEndpoint[0..n]],
                         Dependent[ref ConditioningService[0..1]]
 
 
 4.4.4. The Association EgressConditioningServiceOnEndpoint
 
   This association is derived from the association
   ServiceSAPDependency, and represents the binding, in the egress
   direction, between a protocol endpoint and the last
   ConditioningService that processes packets before they leave a
   network device via that protocol endpoint.  (This "last"
   ConditioningService is ordinarily a scheduler, but it doesn't
   have to be.)  Since there can be multiple "last"
   ConditioningServices for a protocol endpoint in the case of a
   fallback scheduler, the cardinality for the Dependent object
   reference remains 0..n.  Since, however, a single
   ConditioningService cannot be the last one to process packets for
   multiple protocol endpoints, the cardinality of the Antecedent
   object reference is narrowed from 0..n to 0..1.
 
   The class definition is as follows:
 
       NAME              EgressConditioningServiceOnEndpoint
       DESCRIPTION       An association that establishes a
                         dependency relationship between a protocol
                         endpoint and the last conditioning
                         service(s) that process traffic to be
                         transmitted via that protocol endpoint.
       DERIVED FROM      ServiceSAPDependency
       ABSTRACT          False
       PROPERTIES        Antecedent[ref ProtocolEndpoint[0..1]],
                         Dependent[ref ConditioningService[0..n]]
 
 
 4.4.5. The Association HeadTailDropQueueBinding
 
   This association is a subclass of Dependency, describing the
   association between a head or tail dropper and a queue that it
   monitors to determine when to drop traffic.  The referenced queue
   is the one whose queue depth is compared against the Dropper's
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 69]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   threshold.  The cardinality is 1..n on the queue side, since a
   head/tail dropper must monitor at least one queue. For the
   classes HeadTailDropper and HeadTailDropQueueBinding, the rule
   for combining the inputs from multiple queues is simple addition:
   if the sum of the lengths of the monitored queues exceeds the
   dropper's QueueThreshold value, then packets are dropped.  This
   rule for combining inputs may, however, be overridden by a
   different rule in subclasses of one or both of these classes.
 
   The class definition is as follows:
 
       NAME              HeadTailDropQueueBinding
       DESCRIPTION       A generic association used to establish a
                         dependency relationship between a
                         head or tail dropper and a queue that it
                         monitors.
       DERIVED FROM      Dependency
       ABSTRACT          False
       PROPERTIES        Antecedent[ref QueuingService[1..n]],
                         Dependent[ref
                            HeadTailDropperService [0..n]]
 
 
 4.4.6. The Association CalculationBasedOnQueue
 
   This association is a subclass of Dependency, which defines two
   object references that establish a dependency relationship
   between a QueuingService and an instance of the
   DropThresholdCalculationService class.  The queue's current depth
   is used by the calculation service in calculating an average
   queue depth.
 
   The class definition is as follows:
 
       NAME              CalculationBasedOnQueue
       DESCRIPTION       A generic association used to establish a
                         dependency relationship between a
                         QueuingService object and a
                         DropThresholdCalculationService object.
       DERIVED FROM      ServiceServiceDependency
       ABSTRACT          False
       PROPERTIES        Antecedent[ref QueuingService[1..1]],
                         Dependent[ref
                            DropThresholdCalculationService [0..n]]
 
 
 4.4.6.1 The Reference Antecedent
 
   This property is inherited from the Dependency association, and
   overridden to serve as an object reference to a QueuingService
   object (instead of to the more general ManagedElement).  This
   reference identifies the queue that the
   DropThresholdCalculationService will use in its calculation of
   average queue depth.
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 70]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
 4.4.6.2 The Reference Dependent
 
   This property is inherited from the Dependency association, and
   overridden to serve as an object reference to a
   DropThresholdCalculationService object (instead of to the more
   general ManagedElement). This reference identifies a
   DropThresholdCalculationService that uses the referenced queue's
   current depth as one of the inputs to its calculation of average
   queue depth.
 
 4.4.7. The Association ProvidesServiceToElement
 
   This association defines two object references that establish a
   dependency relationship in which a ManagedSystemElement depends
   on the functionality of one or more Services.  The association's
   cardinality is many to many.
 
   The association is defined in the Core Model of CIM.  Please
   refer to [CIM] for the full definition of this class.
 
 4.4.8. The Association ServiceServiceDependency
 
   This association defines two object references that establish a
   dependency relationship between two Service objects.  The
   particular type of dependency is represented by the
   TypeOfDependency property; typical examples include that one
   Service is required to be present or required to have completed
   for the other Service to operate.
 
   This association is very similar to the ServiceSAPDependency
   relationship.  For the latter, the Service is dependent on an
   AccessPoint to get at another Service.  In this relationship, it
   directly identifies its Service dependency.  Both relationships
   should not be instantiated, since their information is
   repetitive.
 
   The association's cardinality is many to many.
 
   The association is defined in the Core Model of CIM.  Please
   refer to [CIM] for the full definition of this class.
 
 4.4.9. The Association CalculationServiceForDropper
 
   This association is a subclass of ServiceServiceDependency, which
   defines two object references that represent the reliance of a
   REDDropperService on a DropThresholdCalculationService -
   calculating an average queue depth based on the observed depths
   of one or more queues.
 
   The class definition is as follows:
 
       NAME              CalculationServiceForDropper
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 71]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
       DESCRIPTION       A generic association used to establish a
                         dependency relationship between a
                         calculation service and a
                         REDDropperSrevice for which it performs
                         average queue depth calculations
       DERIVED FROM      ServiceServiceDependency
       ABSTRACT          False
       PROPERTIES        Antecedent[ref
                            DropThresholdCalculationService[1..n]],
                         Dependent[ref REDDropperService[0..n]]
 
 
 4.4.9.1 The Reference Antecedent
 
   This property is inherited from the ServiceServiceDependency
   association, and overridden to serve as an object reference to a
   DropThresholdCalculationService object (instead of to the more
   general Service object).  The cardinality of the object reference
   is 1..n, indicating that a RED dropper may be served by one or
   more calculation services.
 
 4.4.9.2 The Reference Dependent
 
   This property is inherited from the ServiceServiceDependency
   association, and overridden to serve as an object reference to a
   REDDropperService object (instead of to the more general Service
   object).  This reference identifies a RED dropper served by a
   DropThresholdCalculationService.
 
 4.4.10. The Association QueueAllocation
 
   This association is a subclass of Dependency, which defines two
   object references that establish a dependency relationship
   between a QueuingService and a BufferPool that provides storage
   space for the packets in the queue.
 
   The class definition is as follows:
 
       NAME              QueueAllocation
       DESCRIPTION       A generic association used to establish a
                         dependency relationship between a
                         QueuingService object and a BufferPool
                         object.
       DERIVED FROM      Dependency
       ABSTRACT          False
       PROPERTIES        Antecedent[ref BufferPool[0..n]],
                         Dependent[ref QueuingService[0..n]]
                         AllocationPercentage
 
 
 4.4.10.1 The Reference Antecedent
 
   This property is inherited from the Dependency association, and
   overridden to serve as an object reference to a BufferPool
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 72]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   object.  This reference identifies the BufferPool in which
   packets on the QueuingService's queue are stored.
 
 4.4.10.2 The Reference Dependent
 
   This property is inherited from the Dependency association, and
   overridden to serve as an object reference to a QueuingService
   object.  This reference identifies the QueuingService whose
   packets are being stored in the BufferPool's buffers.
 
 4.4.10.3 The Property AllocationPercentage
 
   This property is an 8-bit unsigned integer with minimum value of
   zero and maximum value of 100.  It defines the percentage of the
   BufferPool that should be allocated to the referenced
   QueuingService.  If absolute sizes are desired, this would be
   accomplished by defining individual BufferPools of the specified
   sizes, with QueueAllocation.AllocationPercentages set to 100.
 
 4.4.11. The Association ClassifierElementUsesFilterList
 
   This association is a subclass of the Dependency association.  It
   relates one or more ClassifierElements with a FilterList
   representing the criteria for selecting packets for each of the
   ClassifierElements to process.
 
   In the QDDIM model, a classifier is always modeled as a
   ClassifierService that aggregates a set of ClassifierElements.
   When ClassifierElements use the NextServiceAfterClassifierElement
   association to bind to another ClassifierService (to construct a
   hierarchical classifier), the ClassifierElementUsesFilterList
   association must not be specified.
 
   The class definition is as follows:
 
       NAME              ClassifierElementUsesFilterList
       DESCRIPTION       An association relating a
                         ClassifierElement to the FilterList
                         representing the criteria for selecting
                         packets for that ClassifierElement to
                         process.
       DERIVED FROM      Dependency
       ABSTRACT          False
       PROPERTIES        Antecedent[ref FilterList [0..1]],
                         Dependent[ref ClassifierElement [0..n]]
 
 
 4.4.11.1 The Reference Antecedent
 
   This property is inherited from the Dependency association, and
   overridden to serve as an object reference to a FilterList
   object, instead of to the more general ManagedElement object.
   Also, its cardinality is restricted to 0 and 1, indicating that a
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 73]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   ClassifierElement uses either one FilterList to select packets
   for it or no FilterList when the ClassifierElement uses the
   NextServiceAfterClassifierElement association to bind to another
   ClassifierService to form a hierarchical classifier.
 
 4.4.11.2 The Reference Dependent
 
   This property is inherited from the Dependency association, and
   overridden to serve as an object reference to a ClassifierElement
   object, instead of to the more general ManagedElement object.
   This reference identifies a ClassifierElement that depends on the
   associated FilterList object to represent its packet-selection
   criteria.
 
 4.4.12. The Association AFRelatedServices
 
   This association defines two object references that establish a
   dependency relationship between two AFService objects.  This
   dependency is the precedence of the individual AF drop-related
   Services within an AF IP packet-forwarding class.
 
   The class definition is as follows:
 
       NAME              AFRelatedServices
       DESCRIPTION       An association used to establish
                         a dependency relationship between two
                         AFService objects.
       DERIVED FROM      Nothing
       ABSTRACT          False
       PROPERTIES        AFLowerDropPrecedence[ref
                           AFService[0..1]],
                          AFHigherDropPrecedence[ref
                           AFService[0..n]]
 
 
 4.4.12.1 The Reference AFLowerDropPrecedence
 
   This property serves as an object reference to an AFService
   object that has the lower probability of dropping packets.
 
 4.4.12.2 The Reference AFHigherDropPrecedence
 
   This property serves as an object reference to an AFService
   object that has the higher probability of dropping packets.
 
 4.4.13. The Association NextService
 
   This association defines two object references that establish a
   predecessor-successor relationship between two
   ConditioningService objects.  This association is used to
   indicate the sequence of ConditioningServices required to process
   a particular type of traffic.
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 74]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   Instances of this dependency describe the various relationships
   between different ConditioningServices (such as classifiers,
   meters, droppers, etc.) that are used collectively to condition
   traffic.  Both one-to-one and more complicated fan-in and/or fan-
   out relationships can be described.  The ConditioningServices may
   feed one another directly, or they may be mapped to multiple
   "next" Services based on the characteristics of the packet.
 
   The class definition is as follows:
 
       NAME              NextService
       DESCRIPTION       An association used to establish
                         a predecessor-successor relationship
                         between two ConditioningService objects.
       DERIVED FROM      Nothing
       ABSTRACT          False
       PROPERTIES        PrecedingService[ref
                           ConditioningService[0..n]],
                         FollowingService[ref
                           ConditioningService[0..n]]
 
 
 4.4.13.1 The Reference PrecedingService
 
   This property serves as an object reference to a
   ConditioningService object that occurs earlier in the processing
   sequence for a given type of traffic.
 
 4.4.13.2 The Reference FollowingService
 
  This property serves as an object reference to a
  ConditioningService object that occurs later in the processing
  sequence for a given type of traffic, immediately after the
  ConditioningService identified by the PrecedingService object
  reference.
 
 4.4.14. The Association NextServiceAfterClassifierElement
 
   This association refines the definition of its superclass, the
   NextService association, in two ways:
 
      o    It restricts the PrecedingService object reference to the
           class ClassifierElement.
 
      o    It restricts the cardinality of the FollowingService
           object reference to exactly 1.
 
   The class definition is as follows:
 
       NAME              NextServiceAfterClassifierElement
       DESCRIPTION       An association used to establish
                         a predecessor-successor relationship
                         between a single ClassifierElement
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 75]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
                         within a Classifier and the next
                         ConditioningService object that is
                         responsible for further processing of
                         the traffic selected by that
                         ClassifierElement.
       DERIVED FROM      NextService
       ABSTRACT          False
       PROPERTIES        PrecedingService
                           [ref ClassifierElement[0..n]],
                         FollowingService
                           [ref ConditioningService[1..1]
 
 
 4.4.14.1 The Reference PrecedingService
 
   This property is inherited from the NextService association.  It
   is overridden in this subclass to restrict the object reference
   to a ClassifierElement, as opposed to the more general
   ConditioningService defined in the NextService superclass.
 
   This property serves as an object reference to a
   ClassifierElement, which is a component of a single
   ClassifierService.  Packets selected by this ClassifierElement
   are always passed to the ConditioningService identified by the
   FollowingService object reference.
 
 4.4.14.2 The Reference FollowingService
 
   This property is inherited from the NextService association.  It
   is overridden in this subclass to restrict the cardinality of the
   reference to exactly 1.  This reflects the requirement that the
   behavior of a DiffServ classifier must be deterministic: the
   packets selected by a given ClassifierElement in a given
   ClassifierService must always go to one and only one next
   ConditioningService.
 
 4.4.15. The Association NextScheduler
 
   This association is a subclass of NextService, and defines two
   object references that establish a predecessor-successor
   relationship between PacketSchedulingServices.  In a hierarchical
   queuing configuration where a second scheduler treats the output
   of a first scheduler as a single, aggregated input, the two
   schedulers are related via the NextScheduler association.
 
   The class definition is as follows:
 
       NAME              NextScheduler
       DESCRIPTION       An association used to establish
                         predecessor-successor relationships
                         between PacketSchedulingService objects
                         for simple hierarchical scheduling.
       DERIVED FROM      NextService
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 76]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
       ABSTRACT          False
       PROPERTIES        PrecedingService[ref
                            PacketSchedulingService[0..n]],
                         FollowingService[ref
                            PacketSchedulingService[0..1]]
 
 
 4.4.15.1 The Reference PrecedingService
 
   This property is inherited from the NextService association, and
   overridden to serve as an object reference to a
   PacketSchedulingService object (instead of to the more general
   ConditioningService object).  This reference identifies a
   scheduler whose output is being treated as a single, aggregated
   input by the scheduler identified by the FollowingService
   reference.  The [0..n] cardinality indicates that a single
   FollowingService scheduler may bring together the aggregated
   outputs of multiple prior schedulers.
 
 4.4.15.2 The Reference FollowingService
 
   This property is inherited from the NextService association, and
   overridden to serve as an object reference to a
   PacketSchedulingService object (instead of to the more general
   ConditioningService object).  This reference identifies a
   scheduler that includes among its inputs the aggregated outputs
   of one or more PrecedingService schedulers.
 
 4.4.16. The Association FailNextScheduler
 
   This association is a subclass of the NextScheduler association.
   FailNextScheduler represents the relationship between two
   schedulers when the first scheduler passes up a scheduling
   opportunity (thereby behaving in a non-work conserving manner),
   and makes the resulting bandwidth available to the second
   scheduler for its use.  See Sections 3.11.3 and 3.11.4 for
   examples of where this association might be used.
 
   The class definition is as follows:
 
       NAME              FailNextScheduler
       DESCRIPTION       This association specializes the
                         NextScheduler association.  It
                         establishes a relationship between a
                         non-work-conserving scheduler and a
                         second scheduler to which it makes
                         available the bandwidth that it elects
                         not to use.
       DERIVED FROM      NextScheduler
       ABSTRACT          False
       PROPERTIES        PrecedingService[ref
                          NonWorkConservingSchedulingService[0..n]]
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 77]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
 4.4.16.1 The Reference PrecedingService
 
   This property is inherited from the NextScheduler association,
   and overridden to serve as an object reference to a
   NonWorkConservingSchedulingService object (instead of to the more
   general PacketSchedulingService object).  This reference
   identifies a non-work-conserving scheduler whose excess bandwidth
   is being made available to the scheduler identified by the
   FollowingService reference.  The [0..n] cardinality indicates
   that a single FollowingService scheduler may have the opportunity
   to use the unused bandwidth of multiple prior non-work-conserving
   schedulers.
 
 
 
 4.4.17. The Association NextServiceAfterMeter
 
   This association describes a predecessor-successor
   relationship between a MeterService and one or more
   ConditioningService objects that process traffic from the
   meter.  For example, for devices that implement preamble
   marking, the FollowingService reference (after the meter)
   is a PreambleMarkerService - to record the results of the
   metering in the preamble.
 
   It might be expected that the NextServiceAfterMeter association
   would subclass from NextService.  However, meters are 1:n fan-out
   elements, and require a mechanism to distinguish between the
   different results/outputs of the meter.  Therefore, this
   association defines a new key property, MeterResult, which is
   used to record the result and identify the output through which
   this traffic left the meter.
 
   The class definition is as follows:
 
       NAME              NextServiceAfterMeter
       DESCRIPTION       An association used to establish
                         a predecessor-successor relationship
                         between a particular output of a
                         MeterService and the next
                         ConditioningService object that is
                         responsible for further processing of
                         the traffic.
       DERIVED FROM      Nothing
       ABSTRACT          False
       PROPERTIES        PrecedingService[ref MeterService[0..n]],
                         FollowingService[ref
                           ConditioningService[0..n]],
                         MeterResult
 
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 78]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
 4.4.17.1 The Reference PrecedingService
 
   The preceding MeterService, 'earlier' in the processing sequence
   for a packet.  Since Meters are 1:n fan-out devices, this
   relationship associates a particular output of a MeterService
   (identified by the MeterResult property) to the next
   ConditioningService that is used to further process the traffic.
 
 4.4.17.2 The Reference FollowingService
 
   The 'next' or following ConditioningService.
 
 4.4.17.3 The Property MeterResult
 
   This property is an enumerated 16-bit unsigned integer, and
   represents information describing the result of the metering.
   Traffic is distinguished as being conforming, non-conforming, or
   partially conforming.  More complicated metering can be built
   either by extending the enumeration or by cascading meters.
 
   The enumerated values are: "Unknown" (0), "Conforming" (1),
   "PartiallyConforming" (2), "NonConforming" (3).
 
 4.4.18. The Association QueueToSchedule
 
   This is a top-level association, representing the relationship
   between a queue (QueuingService) and a SchedulingElement.  The
   SchedulingElement, in turn, represents the information in a
   packet scheduling service that is specific to this queue, such as
   relative priority or allocated bandwidth.
 
   It cannot be expressed formally with the association
   cardinalities, but there is an additional constraint on
   participation in this association.  A particular instance of (a
   subclass of) SchedulingElement always participates either in
   exactly one instance of this association, or in exactly one
   instance of the association SchedulingServiceToSchedule.
 
   The class definition is as follows:
 
       NAME              QueueToSchedule
       DESCRIPTION       This association relates a queue to
                         the SchedulingElement containing
                         information specific to the queue.
       DERIVED FROM      Nothing
       ABSTRACT          False
       PROPERTIES        Queue[ref QueuingService[0..1]],
                         SchedElement[ref
                            SchedulingElement[0..n]]
 
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 79]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
 4.4.19. The Association SchedulingServiceToSchedule
 
   This is a top-level association, representing the relationship
   between a scheduler (PacketSchedulingService) and a
   SchedulingElement, in a configuration involving cascaded
   schedulers.  The SchedulingElement, in turn, represents the
   information in a subsequent packet scheduling service that is
   specific to this scheduler, such as relative priority or
   allocated bandwidth.
 
   It cannot be expressed formally with the association
   cardinalities, but there is an additional constraint on
   participation in this association.  A particular instance of (a
   subclass of) SchedulingElement always participates either in
   exactly one instance of this association, or in exactly one
   instance of the association QueueToSchedule.
 
   The class definition is as follows:
 
       NAME              SchedulingServiceToSchedule
       DESCRIPTION       This association relates a scheduler to
                         the SchedulingElement in a subsequent
                         scheduler containing information specific
                         to this scheduler.
       DERIVED FROM      Nothing
       ABSTRACT          False
       PROPERTIES        SchedService[ref
                            PacketSchedulingService[0..1]],
                         SchedElement[ref
                            SchedulingElement[0..n]]
 
 
 4.4.20. The Aggregation MemberOfCollection
 
   This aggregation is a generic relationship used to model the
   aggregation of a set of ManagedElements in a generalized
   Collection object.  The aggregation's cardinality is many to
   many.
 
   MemberOfCollection is defined in the Core Model of CIM.  Please
   refer to [CIM] for the full definition of this class.
 
 4.4.21. The Aggregation CollectedBufferPool
 
   This aggregation models the ability to treat a set of buffers as
   a pool, or collection, that can in turn be contained in a
   "higher-level" buffer pool.  This class overrides the more
   generic MemberOfCollection aggregation to restrict both the
   aggregate and the part component objects to be instances only of
   the BufferPool class.
 
   The class definition for the aggregation is as follows:
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 80]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
       NAME              CollectedBufferPool
       DESCRIPTION       A generic association used to aggregate
                         a set of related buffers into a
                         higher-level buffer pool.
       DERIVED FROM      MemberOfCollection
       ABSTRACT          False
       PROPERTIES        Collection[ref BufferPool[0..1]],
                         Member[ref BufferPool[0..n]]
 
 
 4.4.21.1 The Reference Collection
 
   This property represents the parent, or aggregate, object in the
   relationship.  It is a BufferPool object.
 
 4.4.21.2 The Reference Member
 
   This property represents the child, or lower level pool, in the
   relationship.  It is one of the set of BufferPools that together
   make up the higher-level pool.
 
 4.4.22. The Abstract Aggregation Component
 
   This abstract aggregation is a generic relationship used to
   establish "part-of" relationships between managed objects (named
   GroupComponent and PartComponent).  The association's cardinality
   is many to many.
 
   The association is defined in the Core Model of CIM.  Please
   refer to [CIM] for the full definition of this class.
 
 4.4.23. The Aggregation ServiceComponent
 
   This aggregation is used to model a set of subordinate Services
   that are aggregated together to form a higher-level Service.
   This aggregation is derived from the more generic Component
   superclass to restrict the types of objects that can participate
   in this relationship.  The association's cardinality is many to
   many.
 
   The association is defined in the Core Model of CIM.  Please
   refer to [CIM] for the full definition of this class.
 
 4.4.24. The Aggregation QoSSubService
 
   This aggregation represents a set of subordinate QoSServices that
   are aggregated together to form a higher-level QoSService.  A
   QoSService is a specific type of Service that conceptualizes QoS
   functionality as a set of coordinated sub-services.
 
   This aggregation is derived from the more generic
   ServiceComponent superclass to restrict the types of objects that
   can participate in this relationship to QoSService objects,
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 81]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   instead of a more generic Service object.  It also restricts the
   cardinality of the aggregate to 0-or-1 (instead of the more
   generic 0-or-more).
 
   The class definition for the aggregation is as follows:
 
       NAME              QoSSubService
       DESCRIPTION       A generic association used to establish
                         "part-of" relationships between a
                         higher-level QoSService object and the
                         set of lower-level QoSServices that
                         are aggregated to create/form it.
       DERIVED FROM      ServiceComponent
       ABSTRACT          False
       PROPERTIES        GroupComponent[ref QoSService[0..1]],
                         PartComponent[ref QoSService[0..n]]
 
 
 4.4.24.1 The Reference GroupComponent
 
   This property is overridden in this aggregation to represent an
   object reference to a QoSService object (instead of to the more
   generic Service object defined in its superclass).  This object
   represents the parent, or aggregate, object in the relationship.
 
 4.4.24.2 The Reference PartComponent
 
   This property is overridden in this aggregation to represent an
   object reference to a QoSService object (instead of to the more
   generic Service object defined in its superclass).  This object
   represents the child, or "component", object in the relationship.
 
 4.4.25. The Aggregation QoSConditioningSubService
 
   This aggregation identifies the set of ConditioningServices that
   together condition traffic for a particular QoSService.
 
   This aggregation is derived from the more generic
   ServiceComponent superclass; it restricts the types of objects
   that can participate in it to ConditioningService and QoSService
   objects, instead of the more generic Service objects.
 
   The class definition for the aggregation is as follows:
 
       NAME              QoSConditioningSubService
       DESCRIPTION       A generic aggregation used to establish
                         "part-of" relationships between a set
                         of ConditioningService objects and the
                         particular QoSService object(s) that they
                         provide traffic conditioning for.
       DERIVED FROM      ServiceComponent
       ABSTRACT          False
       PROPERTIES        GroupComponent[ref QoSService[0..n]],
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 82]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
                         PartComponent[ref
                           ConditioningService[0..n]]
 
 
 4.4.25.1 The Reference GroupComponent
 
   This property is overridden in this aggregation to represent an
   object reference to a QoSService object (instead of to the more
   generic Service object defined in its superclass).  The
   cardinality of the reference remains 0..n, to indicate that a
   given ConditioningService may provide traffic conditioning for 0,
   1, or more than 1 QoSService objects.
 
   This object represents the parent, or aggregate, object in the
   association.  In this case, this object represents the QoSService
   that aggregates one or more ConditioningService objects to
   implement the appropriate traffic conditioning for its traffic.
 
 4.4.25.2 The Reference PartComponent
 
   This property is overridden in this aggregation to represent an
   object reference to a ConditioningService object (instead of to
   the more generic Service object defined in its superclass).  This
   object represents the child, or "component", object in the
   relationship.  In this case, this object represents one or more
   ConditioningService objects that together indicate how traffic
   for a specific QoSService is conditioned.
 
 4.4.26. The Aggregation ClassifierElementInClassifierService
 
   This aggregation represents the relationship between a classifier
   and the classifier elements that provide the fan-out function for
   the classifier.  A classifier typically aggregates multiple
   classifier elements.  A classifier element, however, is
   aggregated only by a single classifier.  See [DSMODEL] and
   [DSMIB] for more about classifiers and classifier elements.
 
   The class definition for the aggregation is as follows:
 
       NAME              ClassifierElementInClassifierService
       DESCRIPTION       An aggregation representing the
                         relationship between a classifier
                         and its classifier elements.
       DERIVED FROM      ServiceComponent
       ABSTRACT          False
       PROPERTIES        GroupComponent[ref
                            ClassifierService[1..1]],
                         PartComponent[ref
                            ClassifierElement[0..n],
                         ClassifierOrder
 
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 83]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
 4.4.26.1 The Reference GroupComponent
 
   This property is overridden in this aggregation to represent an
   object reference to a ClassifierService object (instead of to the
   more generic Service object defined in its superclass).  It also
   restricts the cardinality of the aggregate to 1..1 (instead of
   the more generic 0-or-more), representing the fact that a
   ClassifierElement always exists within the context of exactly one
   ClassifierService.
 
 4.4.26.2 The Reference PartComponent
 
   This property is overridden in this aggregation to represent an
   object reference to a ClassifierElement object (instead of to the
   more generic Service object defined in its superclass).  This
   object represents a single traffic selector for the classifier.
   A ClassifierElement usually has an association to a FilterList
   that provides selection criteria for packets from the traffic
   stream coming into the classifier, and to a ConditioningService
   to which packets selected by these criteria are next forwarded.
 
 4.4.26.3 The Property ClassifierOrder
 
   Because the filters for a classifier can overlap, it is necessary
   to specify the order in which the ClassifierElements aggregated
   by a ClassifierService are presented with packets coming into the
   classifier.  This property is an unsigned 32-bit integer
   representing this order.  Values are represented in ascending
   order: first '1', then '2', and so on.  Different values MUST be
   assigned for each of the ClassifierElements aggregated by a given
   ClassifierService.
 
 4.4.27. The Aggregation EntriesInFilterList
 
   This aggregation is a specialization of the Component
   aggregation; it is used to define a set of filter entries
   (subclasses of FilterEntryBase) that are aggregated by a
   FilterList.
 
   The cardinalities of the aggregation itself are 0..1 on the
   FilterList end, and 0..n on the FilterEntryBase end.  Thus in the
   general case, a filter entry can exist without being aggregated
   into any FilterList.  However, the only way a filter entry can
   figure in the QoS Device model is by being aggregated into a
   FilterList by this aggregation.
 
   See [PCIME] for the definition of this aggregation.
 
 
 
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 84]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
 4.4.28. The Aggregation ElementInSchedulingService
 
   This concrete aggregation represents the relationship between a
   PacketSchedulingService and the set of SchedulingElements that
   tie it to its inputs.
 
   The class definition for the aggregation is as follows:
 
       NAME              ElementInSchedulingService
       DESCRIPTION       An aggregation used to tie a
                         PacketSchedlingService to the
                         configuration information for one of
                         the elements (either a QueuingService or
                         another PacketSchedulingService) that it
                         schedules.
       DERIVED FROM      Component
       ABSTRACT          False
       PROPERTIES        GroupComponent[ref
                           PacketSchedulingService[0..1]],
                         PartComponent[ref
                            SchedulingElement[1..n]
 
 
 
 5. Intellectual Property
 
   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described
   in this document or the extent to which any license under such
   rights might or might not be available; neither does it represent
   that it has made any effort to identify any such rights.
   Information on the IETF's procedures with respect to rights in
   standards-track and standards-related documentation can be found
   in BCP-11.
 
   Copies of claims of rights made available for publication and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the
   use of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF Secretariat.
 
   The IETF invites any interested party to bring to its attention
   any copyrights, patents or patent applications, or other
   proprietary rights which may cover technology that may be
   required to practice this standard.  Please address the
   information to the IETF Executive Director.
 
 
 6. Acknowledgements
 
   The authors wish to thank the participants of the Policy
   Framework and Differentiated Services working groups for their
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 85]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   many helpful comments and suggestions.  Special thanks to Joel
   Halpern, who provided some key technical direction during the
   latter stages of the document's development.
 
 
 7. Security Considerations
 
   Security and denial of service considerations are not explicitly
   considered in this memo, as they are appropriate for the
   underlying policy architecture implementing the distribution and
   communication of the information described in this draft.
   Specifically, any mechanisms used to distribute and communicate
   the information described in this draft must minimize theft and
   denial of service threats.  Second, it must be ensured that the
   entities involved in policy control can verify each other's
   identity and establish necessary trust before communicating.
 
   The communication tunnel between policy clients and policy
   servers SHOULD be secured by the use of an IPSEC [R1825] channel.
   It is advisable that this tunnel makes use of both the AH
   (Authentication Header) and ESP (Encapsulating Security Payload)
   protocols, in order to provide confidentiality, data origin
   authentication, integrity and replay prevention.
 
 
 8. References
 
   [CIM] Common Information Model (CIM) Schema, version 2.5.
       Distributed Management Task Force, Inc.  The components of
       the CIM v2.5 schema are available via links on the following
       DMTF web page: http://www.dmtf.org/spec/cims.html.
 
   [DSMIB] Management Information Base for the Differentiated
       Services Architecture.  Internet Draft, draft-ietf-diffserv-
       mib-16.txt, F. Baker, K. Chan, and A. Smith.  November 2001.
 
 
   [DSMODEL] An Informal Management Model for DiffServ Routers.
       Internet Draft, draft-ietf-diffserv-model-06.txt, Y. Bernet,
       A. Smith, S. Blake, and D. Grossman.  February 2001.
 
   [IEEE802Q] Virtual Bridged Local Area Networks, ANSI/IEEE std
       802.1Q, 1998 edition.  Approved December 8, 1998
 
   [PCIM] Policy Core Information Model - Version 1 Specification.
       RFC 3060, B. Moore, E. Ellesson, J. Strassner, and A.
       Westerinen.  February 2001.
 
   [PCIME] Policy Core Information Model Extensions.  Internet-
       Draft, draft-ietf-policy-pcim-ext-08.txt, B. Moore, May 2002.
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 86]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
   [PIB] Differentiated Services Quality of Service Policy
       Information Base.  Internet Draft, draft-ietf-diffserv-pib-
       06.txt, M. Fine, K. McCloughrie, J. Seligson, K. Chan, S.
       Hahn, C. Bell, A. Smith, and F. Reichmeyer.  March 2002.
 
   [POLTERM] Policy Terminology. RFC 3198, A. Westerinen, et al.
       November 2001.
 
   [QPIM] Policy Framework QoS Information Model.  Internet Draft,
       draft-ietf-policy-qos-info-model-04.txt, Y. Snir, Y. Ramberg,
       J. Strassner, R. Cohen, and B. Moore. November 2001.
 
   [R791] Postel, J., Editor, "Internet Protocol", STD  RFC 791,
       September 1981.
 
   [R1633] Integrated Services in the Internet Architecture: An
       Overview.  R. Braden, D. Clark, and S. Shenker.  June 1994.
 
   [R1825] Security Architecture for the Internet Protocol.  R.
       Atkinson.  August 1995.
 
   [R2119] Key words for use in RFCs to Indicate Requirement
       Levels. S. Bradner.  March 1997.
 
   [R2474] Definition of the Differentiated Services Field (DS
       Field) in the IPv4 and IPv6 Headers.  K. Nichols, S. Blake,
       F. Baker, and D. Black.  December 1998.
 
   [R2475] An Architecture for Differentiated Service.  S. Blake,
       D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss.
       December 1998.
 
   [R2597] Assured Forwarding PHB Group.  J. Heinanen, F. Baker, W.
       Weiss, and J. Wroclawski.  June 1999.
 
   [R2598] An Expedited Forwarding PHB.  V. Jacobson, K. Nichols,
       and K. Poduri.  June 1999.
 
   [R3140] Per Hop Behavior Identification Codes.  D. Black, S.
       Brim, B. Carpenter, and F. Le Faucheur.  June 2001.
 
   [RED] See http://www.aciri.org/floyd/red.html.
 
 
 9. Authors' Addresses
 
   Bob Moore
      P. O. Box 12195, BRQA/B501/E116
      3039 Cornwallis Rd.
      Research Triangle Park, NC  27709-2195
      Phone:  +1-919-254-4436
 
      E-mail:  remoore@us.ibm.com
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 87]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   David Durham
      Intel
      2111 NE 25th Avenue
      Hillsboro, OR 97124
      Phone: (503) 264-6232
      Email: david.durham@intel.com
 
   John Strassner
      INTELLIDEN, Inc.
      90 South Cascade Avenue
      Colorado Springs, CO  80903
      Phone:   +1-719-785-0648
      E-mail:   john.strassner@intelliden.com
 
   Andrea Westerinen
      Cisco Systems, Bldg 20
      725 Alder Drive
      Milpitas, CA 95035
      E-mail:  andreaw@cisco.com
 
   Walter Weiss
      Ellacoya Networks
      7 Henry Clay Dr.
      Merrimack, NH 03054
      Phone: +1-603-879-7364
      E-mail: wweiss@ellacoya.com
 
 10. Full Copyright Statement
 
   Copyright (C) The Internet Society (2001).  All Rights Reserved.
 
   This document and translations of it may be copied and furnished
   to others, and derivative works that comment on or otherwise
   explain it or assist in its implementation may be prepared,
   copied, published and distributed, in whole or in part, without
   restriction of any kind, provided that the above copyright notice
   and this paragraph are included on all such copies and derivative
   works.  However, this document itself may not be modified in any
   way, such as by removing the copyright notice or references to
   the Internet Society or other Internet organizations, except as
   needed for the purpose of developing Internet standards in which
   case the procedures for copyrights defined in the Internet
   Standards process must be followed, or as required to translate
   it into languages other than English.
 
   The limited permissions granted above are perpetual and will not
   be revoked by the Internet Society or its successors or assigns.
 
   This document and the information contained herein is provided on
   an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 88]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
   IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
   PURPOSE.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 89]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
 
 11. Appendix A:  Naming Instances in a Native CIM Implementation
 
   Following the precedent established in [PCIM], this document has
   placed the details of how to name instances of its classes in a
   native CIM implementation here in an appendix.  Since Appendix A
   in [PCIM] has a lengthy discussion of the general principles of
   CIM naming, this appendix does not repeat that information here.
   Readers interested in a more global discussion of how instances
   are named in a native CIM implementation should refer to [PCIM].
 
 11.1. Naming Instances of the Classes Derived from Service
 
   Most of the classes defined in this model are derived from the
   CIM class Service.  Although Service is an abstract class, it
   nevertheless has key properties included as part of its
   definition.  The purpose of including key properties in an
   abstract class is to have instances of all of its instantiable
   subclasses named in the same way.  Thus, the majority of the
   classes in this model name their instances in exactly the same
   way: with the two key properties CreationClassName and Name that
   they inherit from Service.
 
 11.2. Naming Instances of Subclasses of FilterEntryBase
 
   Like Service, FilterEntryBase (defined in [PCIME]) is an abstract
   class that includes key properties in its definition.
   FilterEntryBase has four key properties.  Two of them,
   SystemCreationClassName and SystemName, are propagated to it via
   the weak association FilterEntryInSystem.  The other two,
   CreationClassName and Name, are native to FilterEntryBase.
 
   Thus instances of all of the subclasses of FilterEntryBase,
   including the PreambleFilter class defined here, are named in the
   same way: with the four key properties they inherit from
   FilterEntryBase.
 
 11.3. Naming Instances of ProtocolEndpoint
 
   The class ProtocolEndpoint inherits its key properties from its
   superclass, ServiceAccessPoint.  These key properties provide the
   same naming structure that we've seen before: two propagated key
   properties SystemCreationClassName and SystemName, plus two
   native key properties CreationClassName and Name.
 
 11.4. Naming Instances of BufferPool
 
   Unlike the other classes in this model, BufferPool is not derived
   from Service.  Consequently, it does not inherit its key
   properties from Service.  Instead, it inherits one of its key
   properties, CollectionID, from its superclass Collection, and
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 90]


 Internet Draft         QoS Device Datapath Info Model          May 2002
 
 
   adds its other key property, CreationClassName, in its own
   definition.
 
 11.4.1. The Property CollectionID
 
   CollectionID is a string property with a maximum length of 256
   characters.  It identifies the buffer pool.  Note that this
   property is defined in the BufferPool class's superclass,
   CollectionOfMSEs, but not as a key property.  It is overridden in
   BufferPool, to make it part of this class's composite key.
 
 11.4.2. The Property CreationClassName
 
   This property is a string property of with a maximum length of
   256 characters.  It is set to "CIM_BufferPool" if this class is
   directly instantiated, or to the class name of the BufferPool
   subclass that is created.
 
 11.5. Naming Instances of SchedulingElement
 
   This class has not yet been incorporated into the CIM model, so
   it does not have any CIM naming properties yet.  If the normal
   pattern is followed, however, instances will be named with two
   properties CreationClassName and Name.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Moore, et al.     Expires: May 2002 + 6 months                [Page 91]

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