tech-invite   World Map     

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

RFC 3670

 
 
 

Information Model for Describing Network Device QoS Datapath Mechanisms

Part 4 of 4, p. 70 to 97
Prev RFC Part

 


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

Top      Up      ToC       Page 71 
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 first to process packets
   received via multiple protocol endpoints, the cardinality of the
   Antecedent object reference remains 0..n.

Top      Up      ToC       Page 72 
   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
   threshold.  The cardinality is 1..n on the queue side, since a

Top      Up      ToC       Page 73 
   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]]

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

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.

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

Top      Up      ToC       Page 76 
   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 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

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

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

   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.

Top      Up      ToC       Page 79 
   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 within
                        a Classifier and the next
                        ConditioningService object that is
                        responsible for further processing of
                        the traffic selected by that
                        ClassifierElement.

Top      Up      ToC       Page 80 
      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
      ABSTRACT          False

Top      Up      ToC       Page 81 
      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

Top      Up      ToC       Page 82 
      PROPERTIES        PrecedingService[ref
                         NonWorkConservingSchedulingService[0..n]]

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.
   Because of this additional key, NextServiceAfterMeter cannot be a
   subclass of NextService.

   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

Top      Up      ToC       Page 83 
      PROPERTIES        PrecedingService[ref MeterService[0..n]],
                        FollowingService[ref
                          ConditioningService[0..n]],
                        MeterResult

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.

Top      Up      ToC       Page 84 
   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]]

4.4.18.1.  The Reference Queue

   This property serves as an object reference to a QueuingService
   object.  A QueuingService object may be associated 0 or more
   SchedulingElement objects.

4.4.18.2.  The Reference SchedElement

   This property serves as an object reference to a SchedulingElement
   object.  A SchedulingElement is always associated either with exactly
   one QueuingService or with exactly one upstream scheduler
   (PacketSchedulingService).

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.

Top      Up      ToC       Page 85 
      DERIVED FROM      Nothing
      ABSTRACT          False
      PROPERTIES        SchedService[ref
                           PacketSchedulingService[0..1]],
                        SchedElement[ref
                           SchedulingElement[0..n]]

4.4.19.1.  The Reference SchedService

   This property serves as an object reference to a
   PacketSchedulingService object.  A PacketSchedulingService object may
   be associated 0 or more SchedulingElement objects.

4.4.19.2.  The Reference SchedElement

   This property serves as an object reference to a SchedulingElement
   object.  A SchedulingElement is always associated either with exactly
   one QueuingService or with exactly one upstream scheduler
   (PacketSchedulingService).

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:

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

Top      Up      ToC       Page 86 
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 QoSService objects
   (that is, a set of instances of subclasses of the QoSService class)
   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, 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).

Top      Up      ToC       Page 87 
   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 conditioning services that
   together condition traffic for a particular QoS service.

   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

Top      Up      ToC       Page 88 
      PROPERTIES        GroupComponent[ref QoSService[0..n]],
                        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

Top      Up      ToC       Page 89 
      PROPERTIES        GroupComponent[ref
                           ClassifierService[1..1]],
                        PartComponent[ref
                           ClassifierElement[0..n],
                        ClassifierOrder

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

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

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]

4.4.28.1.  The Reference GroupComponent

   This property is overridden in this aggregation to represent an
   object reference to a PacketSchedulingService object (instead of to
   the more generic Service object defined in its superclass). It also
   restricts the cardinality of the aggregate to 0..1 (instead of the
   more generic 0-or-more), representing the fact that a
   SchedulingElement exists within the context of at most one
   PacketSchedulingService.

4.4.28.2.  The Reference PartComponent

   This property is overridden in this aggregation to represent an
   object reference to a SchedulingElement object (instead of to the
   more generic Service object defined in its superclass).  This object
   represents a single scheduling element for the scheduler. It also
   restricts the cardinality of the SchedulingElement to 1..n (instead
   of the more generic 0-or-more), representing the fact that a
   PacketSchedulingService always includes at least one
   SchedulingElement.

Top      Up      ToC       Page 91 
5.  Intellectual Property Statement

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

   Like [PCIM] and [PCIME], this document defines an information model
   that cannot be implemented directly.  Consequently, security issues
   do not arise until it is mapped to an actual, implementable data
   model such as a MIB, PIB, or LDAP schema.  See [PCIM] for a general
   discussion of security considerations for information models.  See
   also [DSMIB] (which in fact is a data model that corresponds to a
   large extent with the QDDIM information model), for a discussion of
   the security implications of specific objects in the model.

Top      Up      ToC       Page 92 
8.  References

8.1.  Normative References

   [CIM]      Common Information Model (CIM) Schema, version 2.5.
              Distributed Management Task Force, Inc., available at
              http://www.dmtf.org/standards/cim_schema_v25.php.

   [IEEE802Q] Virtual Bridged Local Area Networks, ANSI/IEEE std 802.1Q,
              1998 edition.  Approved December 8, 1998

   [PCIM]     Moore, B., Ellesson, E., Strassner, J. and A. Westerinen,
              "Policy Core Information Model - Version 1 Specification",
              RFC 3060, February 2001.

   [PCIME]    Moore, B., Ed., "Policy Core Information Model (PCIM)
              Extensions", RFC 3460, January 2003.

   [R791]     Postel, J., "Internet Protocol", STD 5, RFC 791, September
              1981.

   [R2119]    Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

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

   [R3140]    Black, D., Brim, S., Carpenter, B. and F. Le Faucheur,
              "Per Hop Behavior Identification Codes", RFC 3140, June
              2001.

8.2.  Informative References

   [DSMIB]    Baker, F., Chan, K. and A. Smith, "Management Information
              Base for the Differentiated Services Architecture", RFC
              3289, May 2002.

   [DSMODEL]  Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An
              Informal Management Model for DiffServ Routers", RFC 3290,
              May 2002.

Top      Up      ToC       Page 93 
   [PIB]      Chan, K., Sahita, R., Hahn, S. and K. McCloghrie,
              "Differentiated Services Quality of Service Policy
              Information Base", RFC 3317, March 2003.

   [POLTERM]  Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
              M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
              J. and S. Waldbusser, "Terminology for Policy-Based
              Management", RFC 3198, November 2001.

   [QPIM]     Snir, Y., Ramberg, Y., Strassner, J., Cohen, R. and B.
              Moore, "Policy Quality of Service (QoS) Information
              Model", RFC 3644, November 2003.

   [R1633]    Braden, R., Clark, D. and S. Shenker, "Integrated Services
              in the Internet Architecture: An Overview",  RFC 1633,
              June 1994.

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

   [R3246]    Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le
              Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V. and D.
              Stiliadis, "An Expedited Forwarding PHB (Per-Hop
              Behavior)", RFC 3246, March 2002.

   [RED]      See http://www.aciri.org/floyd/red.html

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

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

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

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

Top      Up      ToC       Page 95 
9.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 adds its other key
   property, CreationClassName, in its own definition.

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

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

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

Top      Up      ToC       Page 96 
10.  Authors' Addresses

   Bob Moore
   P. O. Box 12195, BRQA/B501/G206
   3039 Cornwallis Rd.
   Research Triangle Park, NC  27709-2195

   Phone: (919) 254-4436
   EMail: remoore@us.ibm.com


   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: (719) 785-0648
   EMail: john.strassner@intelliden.com


   Andrea Westerinen
   Cisco Systems, Bldg 20
   725 Alder Drive
   Milpitas, CA 95035

   EMail: andreaw@cisco.com


   Walter Weiss
   Ellacoya Networks
   7 Henry Clay Dr.
   Merrimack, NH 03054

   Phone: (603) 879-7364
   EMail: walterweiss@attbi.com

Top      Up      ToC       Page 97 
11.  Full Copyright Statement

   Copyright (C) The Internet Society (2004).  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 assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

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