Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3670

Information Model for Describing Network Device QoS Datapath Mechanisms

Pages: 97
Proposed Standard
Part 4 of 4 – Pages 70 to 97
First   Prev   None

Top   ToC   RFC3670 - Page 70   prevText

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   ToC   RFC3670 - 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   ToC   RFC3670 - 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   ToC   RFC3670 - 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   ToC   RFC3670 - 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   ToC   RFC3670 - 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   ToC   RFC3670 - 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   ToC   RFC3670 - 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   ToC   RFC3670 - 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   ToC   RFC3670 - 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   ToC   RFC3670 - 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   ToC   RFC3670 - 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   ToC   RFC3670 - 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   ToC   RFC3670 - 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   ToC   RFC3670 - 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   ToC   RFC3670 - 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   ToC   RFC3670 - 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   ToC   RFC3670 - 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   ToC   RFC3670 - 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   ToC   RFC3670 - 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   ToC   RFC3670 - 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   ToC   RFC3670 - 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   ToC   RFC3670 - 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   ToC   RFC3670 - 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   ToC   RFC3670 - 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   ToC   RFC3670 - 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   ToC   RFC3670 - 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   ToC   RFC3670 - 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.