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 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 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.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 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]] AllocationPercentage4.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
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.
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.
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.
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
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]]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
PROPERTIES PrecedingService[ref MeterService[0..n]], FollowingService[ref ConditioningService[0..n]], MeterResult4.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]]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.
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]]
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).
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
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
PROPERTIES GroupComponent[ref ClassifierService[1..1]], PartComponent[ref ClassifierElement[0..n], ClassifierOrder4.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.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.
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.
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.
[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
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.
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.
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
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.