Policy Framework Working Group J. Strassner
INTERNET-DRAFT A. Westerinen
Category: Standards Track Cisco Systems
Bob Moore
IBM Corporation
July 2000
Information Model for Describing Network Device QoS Mechanisms
<draft-ietf-policy-qos-device-info-model-01.txt>
Friday, July 14, 2000, 12:15 PM
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Strassner, et al. Expires: Jul 2000 + 6 months [Page 1]
Internet Draft QoS Device Info Model July 2000
Abstract
The purpose of this draft is to define an information model that
describes the QoS mechanisms inherent in different network
devices. Broadly speaking, these mechanisms describe the
attributes common to selecting and conditioning traffic through
the forwarding path of network devices running Differentiated
Services (see [R2475]). The next version of this draft will also
address Integrated Services (see [R1633]).
This draft is intended to be used with the QoS Policy Information
Model [QOSPIM] to model how policies can be defined to manage and
configure the QoS mechanisms (e.g., the classification, marking,
metering, dropping, queuing, and scheduling functionality) of
devices. Together, these two drafts describe how to write QoS
policy rules to configure and manage the QoS mechanisms of
devices.
This draft, as well as [QOSPIM], are information models. That is,
they represent information independent of binding to a specific
type of repository. A separate draft will be written to provide a
mapping of the data contained in this document to a form suitable
for implementation in a directory that uses (L)DAP as its access
protocol. This latter draft is analogous to [QOSSCH], which
provides a similar mapping of the data in [QOSPIM] to a
directory. Together, these drafts (information models and schema
mappings) then describe how to write QoS policy rules that can be
used to store information in directories to configure device QoS
mechanisms.
Definition of Key Word Usage
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119 [R2119].
Strassner, et al. Expires: Jul 2000 + 6 months [Page 2]
Internet Draft QoS Device Info Model July 2000
Table of Contents
1. Introduction...................................................5
1.1. Policy Management Conceptual Model........................6
1.2. Purpose and Relation to Other Policy Work.................6
1.3. Typical Examples of Policy Usage..........................7
2. Approach.......................................................7
2.1. Common Needs Of DiffServ and IntServ......................7
2.2. Specific Needs Of DiffServ................................8
2.3. Specific Needs Of IntServ.................................9
3. Methodology....................................................9
3.1. Level of Abstraction for Expressing QoS Policies..........9
3.2. Specifying Policy Parameters.............................11
3.3. Specifying Policy Services...............................12
3.4. Level of Abstraction for Defining QoS Attributes and
Classes.......................................................12
3.5. Characterization of QoS Attributes.......................13
3.6. Identifying Common Shared Policies.......................14
3.7. QoS Information Model Derivation.........................15
3.8. Attribute Representation.................................16
3.9. Mental Model.............................................16
3.9.1. The QoSService Class...................................17
3.9.2. The ConditioningService Class..........................18
3.9.3. QoS Statistics Classes.................................19
4. The Class Hierarchy...........................................19
4.1. Difference Between Inheritance and Relationship
Associations..................................................19
4.1.1. Associations...........................................19
4.1.2. Aggregations...........................................20
4.2. The Structure of the Class Hierarchy.....................21
4.2.1. The Class Hierarchy for Modeling State Information.....21
4.2.2. The Class Hierarchy for Modeling Configuration
Information...................................................24
4.3. Class Definitions for the State Portion of the Model.....24
4.3.1. The Class ManagedElement...............................25
4.3.2. The Class ManagedSystemElement.........................25
4.3.3. The Class LogicalElement...............................25
4.3.4. The Class Service......................................25
4.3.5. The Class NetworkService...............................25
4.3.6. The Class ForwardingService............................26
4.3.7. The Class ConditioningService..........................26
4.3.8. The Class ClassifierService............................27
4.3.9. The Class MeterService.................................28
4.3.10. The Class AverageRateMeter............................29
4.3.11. The Class EWMAMeter...................................30
4.3.12. The Class TokenBucketMeter............................31
4.3.13. The Class MarkerService...............................32
4.3.14. The Class DropperService..............................33
4.3.15. The Class REDDropperService...........................35
4.3.16. The Class WeightedREDDropperService...................36
4.3.17. The Class QueuingService..............................37
4.3.18. The Class PacketSchedulingService.....................38
Strassner, et al. Expires: Jul 2000 + 6 months [Page 3]
Internet Draft QoS Device Info Model July 2000
4.3.19. The Class PrioritySchedulingService...................39
4.3.20. The Class PriorityBandwidthSchedulingService..........40
4.3.21. The Class BandwidthSchedulingService..................40
4.3.22. The Class RoundRobinPacketSchedulingService...........41
4.3.23. The Class WeightedRoundRobinPacketSchedulingService...42
4.3.24. The Class QoSService..................................42
4.3.25. The Class DiffServService.............................43
4.3.26. The Class AFService...................................44
4.3.27. The Class EFService...................................45
4.3.28. The Class PrecedenceService...........................45
4.3.29. The Class 8021PService................................46
4.3.30. The Class FilterEntryBase.............................47
4.3.31. The Class FilterEntry.................................47
4.3.32. The Class FilterList..................................48
4.3.33. The Class ServiceAccessPoint..........................49
4.3.34. The Class ProtocolEndpoint............................49
4.3.35. The Class Collection..................................49
4.3.36. The Class CollectionOfMSEs............................49
4.3.37. The Class BufferPool..................................49
4.4. Relationships Defined in the State Portion of the Model..51
4.4.1. The Association Dependency.............................51
4.4.2. The Association ServiceSAPDependency...................51
4.4.3. The Association ConditioningServiceOnEndpoint..........51
4.4.4. The Association ServiceServiceDependency...............52
4.4.5. The Association QueueHierarchy.........................53
4.4.6. The Association SchedulerUsed..........................54
4.4.7. The Association AFRelatedServices......................54
4.4.8. The Association NextService............................55
4.4.9. The Association NextServiceAfterMeter..................56
4.4.10. The Aggregation Component.............................57
4.4.11. The Aggregation ServiceComponent......................57
4.4.12. The Aggregation QoSSubService.........................57
4.4.13. The Aggregation QoSConditioningSubService.............58
4.4.14. The Aggregation MemberOfCollection....................59
4.4.15. The Aggregation CollectedBufferPool...................59
4.4.16. The Aggregation EntriesInFilterList...................60
5. Intellectual Property.........................................60
6. Acknowledgements..............................................61
7. Security Considerations.......................................61
8. References....................................................61
9. Authors' Addresses............................................63
10. Full Copyright Statement.....................................63
Strassner, et al. Expires: Jul 2000 + 6 months [Page 4]
Internet Draft QoS Device Info Model July 2000
1. Introduction
The purpose of this draft is to define an information model that
describes the QoS mechanisms inherent in different network
devices. Broadly speaking, these mechanisms describe the
attributes common to selecting and conditioning traffic through
the forwarding path of network devices running Differentiated
Services (see [R2475]). The next version of this draft will also
address Integrated Services (see [R1633]).
This draft is intended to be used with the QoS Policy Information
Model [QOSPIM] to model how policies can be defined to manage and
configure the QoS mechanisms (e.g., the classification, marking,
metering, dropping, queuing, and scheduling functionality) of
devices. Together, these two drafts describe how to write QoS
policy rules to configure and manage the QoS mechanisms of
devices.
This draft, as well as [QOSPIM], are information models. That is,
they represent information independent of binding to a specific
type of repository. A separate draft will be written to provide a
mapping of the data contained in this document to a form suitable
for implementation in a directory that uses (L)DAP as its access
protocol. This latter draft is analogous to [QOSSCH], which
provides a similar mapping of the data in [QOSPIM] to a
directory. Together, these drafts (information models and schema
mappings) then describe how to write QoS policy rules that can be
used to store information in directories to configure device QoS
mechanisms.
The approach taken in this draft enables a common set of
attributes to be defined that can be used to model Differentiated
Services QoS. (Integrated Services will be modeled in the next
release of this Draft.) Vendors can then map these attributes,
either directly or using a proxy agent like a PIB, to their own
device-specific implementations.
This draft explicitly separates the concepts of configuration and
state. Configuration attributes are used to describe the desired
state of the device, whereas state attributes reflect the current
operation of the device. Both state as well as configuration
attributes are necessary in order to model and manage QoS at the
device level. Although configuration is discussed, the draft only
models state attributes at this time. Configuration will be added
in a future draft.
The design of the class and relationship hierarchies described in
this draft is influenced from the DMTF Network information model
[CIM]. It is specifically not derived from the Policy Core
information model [PCIM]. This is because the modeling of the
QoS mechanisms of a device is separate and distinct from the
Strassner, et al. Expires: Jul 2000 + 6 months [Page 5]
Internet Draft QoS Device Info Model July 2000
modeling of policies that manage those mechanisms. Hence, there
is a need to separate QoS mechanisms (this draft) from their
control (specified using the generic policy draft [PCIM]
augmented by the QoS Policy draft [QOSPIM]).
1.1. Policy Management Conceptual Model
The [PCIM] describes a general methodology for constructing
policy rules. A policy rule aggregates a set of policy conditions
and policy actions. The semantics of a policy rule are such that
if the set of conditions evaluates to TRUE, then the set of
actions are executed.
Policy conditions and actions have two principle components,
operands and operators. Operands can be constants or variables.
A policy can not be constructed without specifying the operands
to be examined, the operands to be changed, and how they should
be bound together.
Operands can be specified at a high-level, such as Joe (a user)
or Gold (a service). Operands can also be specified at a much
finer level of detail, one that is much closer to the operation
of the device. Examples of the latter include an IP Address or a
queue's bandwidth allocation. Implicit in the use of operands is
the binding of legal values or ranges of values to an operand.
For example, the value of an IP address cannot be an integer.
These concepts are defined in this draft and in [QOSPIM].
The second component of policy conditions and actions is a set of
operators. Operators can express both relationships (greater
than, member of a set, Boolean OR, etc.) as well as assignments.
Together, operators and operands can express a variety of
conditions and actions, such as:
If Bob is an Engineer...
If the source IP address is in the Marketing Subnet...
Set Joe's IP address to 2.3.4.5
Limit the bandwidth of application x to 10 Mb
We recognize that the definition of operator semantics is
critical to the definition of policies. However, the definition
of these operators is beyond the scope of this document. Rather,
this draft (with [QOSPIM]) takes the first steps in identifying
and standardizing a set of attributes (operands) for use in
policies.
1.2. Purpose and Relation to Other Policy Work
This model establishes a canonical model of the QoS mechanisms of
a network device (e.g., router or switch) that is independent of
any specific type of network device. This enables traffic to be
Strassner, et al. Expires: Jul 2000 + 6 months [Page 6]
Internet Draft QoS Device Info Model July 2000
described using a common set of abstractions, modeled as a set of
services and sub-services.
When the concepts of this draft are used in conjunction with the
concepts of [QOSPIM], then one is able to define policies that
bind the services in a network to the needs of applications using
that network. In other words, the business requirements of an
organization can be reflected in one set of policies, and those
policies can be translated to a lower-level set of policies that
control and manage the configuration and operation of network
devices.
1.3. Typical Examples of Policy Usage
Policies could be implemented as low-level rules using the
information model described in this specification. For example,
in a low-level policy, a condition could be represented as an
evaluation of a specific attribute from this model. Therefore, a
condition such as "If filter = HTTP" would be interpreted as a
test determining whether any HTTP filters have been defined for
the device. A high-level policy, such as "If HTTP, Then mark with
DSCP 24", would be expressed as a series of actions in a low-
level policy using the classes and attributes described below:
1. Create HTTP filter
2. Create DSCP marker with the value of 24
3. Bind the HTTP filter to the DSCP marker
Using this approach to representing policies, all the semantics
of the policy are preserved.
2. Approach
QoS activities in the IETF have mainly focused in two areas,
Integrated Services (IntServ) and Differentiated Services
(DiffServ) (see [POLTERM], [R1633] and [R2475]). This version of
this draft focuses on the specification of QoS attributes and
classes for the policy management of Differentiated Services.
However, the framework defined by the structure of the classes
defined in this document has been designed with the needs of
IntServ in mind.
2.1. Common Needs Of DiffServ and IntServ
First, let us consider IntServ. IntServ has two principle
components. One component is embedded in the forwarding engine of
the networking device. Its functions include the classification
and policing of individual flows and scheduling admitted packets
for the outbound link. The other component of IntServ is the
management of the signaling protocol (e.g., the PATH and RESV
messages of RSVP). This component processes reservation requests,
Strassner, et al. Expires: Jul 2000 + 6 months [Page 7]
Internet Draft QoS Device Info Model July 2000
manages bandwidth, outsources decision making to policy servers,
and interacts with the Routing Table manager.
We will take RSVP into consideration when defining the structure
of this information model. As this draft initially focuses on the
forwarding engine, elements of RSVP applicable to the forwarding
engine will be considered in the structure of the classes.
This draft models a small subset of the QoS policy problem in
hopes of constructing a methodology that can be adapted for other
aspects of QoS in particular, and policy construction in general.
The focus in this iteration of the draft is on QoS as applied to
DiffServ.
DiffServ operates exclusively in the forwarding engine. It has
all of the same components of the IntServ forwarding engine with
two major differences. First, DiffServ performs classification
based solely on the DSCP field, whereas IntServ examines a subset
of a standard flow's addressing 5-tuple. However, there are
special cases in DiffServ where the addressing 5-tuple (or other
parameters) can be examined. Most notably, this can occur at the
boundary between a DS domain and a non-DS domain. However, most
routers in a DiffServ domain will only need to classify based on
the DSCP field.
The second difference between IntServ and DiffServ is that the
signaling protocol used in IntServ (e.g., RSVP) affects the
forwarding engine in a more dynamic fashion. This is because each
newly admitted RSVP reservation requires a reconfiguration of the
forwarding engine. In contrast, DiffServ requires far fewer
changes to the forwarding engine after the PHBs have been
configured.
The approach advocated in this draft for the creation of policies
that control the various QoS mechanisms of networking devices is
to first identify the attributes with which policies are to be
constructed. These attributes are the parameters used in
expressions that are necessary to construct policies. There is
also a parallel desire to define the operators, relations, and
precedence constructs necessary to construct the conditions and
actions that constitute these policies. However, these efforts
are beyond the scope of this document.
2.2. Specific Needs Of DiffServ
DiffServ-specific rules focus on two particular areas: the core
and the edges of the network. As explained in the DiffServ
Architecture document [R2475], the edge of the network is used to
classify traffic into different traffic streams. The core of the
network then forwards traffic from different streams by using a
set of Per-Hop Behaviors (PHBs). The PHB is defined by a DiffServ
Code Point (DSCP). The DSCP is part of the IP header of each
Strassner, et al. Expires: Jul 2000 + 6 months [Page 8]
Internet Draft QoS Device Info Model July 2000
packet (as described in [R2474]). This enables multiple traffic
streams to be aggregated into a small number of aggregated
traffic streams, where each aggregate traffic stream is forwarded
using a particular PHB.
The attributes used to manipulate QoS capabilities in the core of
the network primarily address the behavioral characteristics of
each supported DiffServ class (or queue). At the edges of the
DiffServ network, the additional complexities of flow
classification, policing, RSVP mappings, remarkings, and other
factors have to be considered. Additional modeling will be
required in this area. However, first, the standards for edges
of the DiffServ network need more detail - to allow the edges to
be incorporated into the policy model.
This draft will initially focus on the core of the DiffServ
network. However, it is expected that as the DiffServ standards
evolve to better define the semantics of edge devices, these
attributes will also be added to the QoS schema presented in this
document.
2.3. Specific Needs Of IntServ
This first iteration of this document will focus exclusively on
the forwarding aspects of network QoS. Therefore, while the
forwarding aspects of IntServ will be considered, the management
of IntServ will not be considered. This will be addressed in a
future iteration of this draft.
3. Methodology
There is a clear need to define attributes and behavior that
together define how traffic should be conditioned. This draft
defines a set of classes and relationships that define the QoS
mechanisms used to condition traffic; [QOSPIM] is used to define
policies to control the QoS mechanisms defined in this draft.
However, there are some very basic issues that need to be
considered when combining these drafts. Considering these issues
should help in constructing a schema for managing the operation
and configuration of network QoS mechanisms through the use of
QoS policies.
3.1. Level of Abstraction for Expressing QoS Policies
The first issue requiring consideration is the level of
abstraction at which QoS policies should be expressed. If we
consider policies as a set of rules used to react to events and
manipulate attributes or generate new events, we realize that
policy represents a continuum of specifications that relate
business goals and rules to the conditioning of traffic done by a
Strassner, et al. Expires: Jul 2000 + 6 months [Page 9]
Internet Draft QoS Device Info Model July 2000
device or a set of devices. An example of a business level policy
might be: from 1:00 pm PST to 7:00 am EST, sell off 40% of the
network capacity on the open market. In contrast, a device-
specific policy might be: if the queue depth grows at a geometric
rate over a specified duration, trigger a potential link failure
event.
A general model for this continuum is shown in Figure 1 below.
+---------------------+
| High-Level Business | Not directly related to device
| Policies | operation and configuration details
+---------------------+
|
|
+---------V-----------+
| Device-Independent | Translate high-level policies to
| Policies | general device operational and
+---------------------+ configuration information
|
|
+---------V-----------+
| Device-Dependent | Translate generic device information
| Policies | to specify how particular devices
+---------------------+ should operate and be configured
Figure 1. The policy continuum
High-level business policies are used to express the requirements
of the different applications, and prioritize which applications
get "better" treatment when the network is congested. The goal,
then, is to use policies to relate the operational and
configuration needs of a device directly to the business rules
that the network administrator is trying to implement (in the
network that the device belongs to).
Device-independent policies translate business policies into a
set of generalized operational and configuration policies that
are independent of any specific device. Not only does this enable
different types of devices (i.e., routers, switches, firewalls,
and hosts) to be controlled by QoS policies, it also enables
devices made by different vendors that use different types of QoS
mechanisms to be controlled. This enables these different devices
to each supply the correct relative conditioning to the same type
of traffic.
In contrast, device-dependent policies translate device-
independent policies into ones that are specific for a given
device. The reason that a distinction is made between device-
independent and device-dependent policies is that in a given
network, many different devices having many different
capabilities (and hence many different mechanisms) need to be
Strassner, et al. Expires: Jul 2000 + 6 months [Page 10]
Internet Draft QoS Device Info Model July 2000
controlled together. Device-independent policies provide a common
layer of abstraction for managing multiple devices of different
capabilities, while device-dependent policies implement the
specific conditioning that is required. This draft provides a
common set of abstractions for representing QoS mechanisms in a
device-independent way.
This draft is focused on the device-independent representation of
policies. QoS mechanisms are modeled in sufficient detail as to
provide a common device-independent representation of QoS
policies. They can also be used to provide a basis for
specialization, enabling each vendor to derive a set of vendor-
specific classes that represent how traffic conditioning is done
for that vendorÆs set of devices. This model also contains hooks
to enable it to be combined with the QoS policy information model
as described in [QOSPIM].
3.2. Specifying Policy Parameters
Policies are a function of parameters (attributes) and operators
(boolean, arithmetic, relational, etc.). Therefore, both need to
be defined as part of the same policy in order to correctly
condition the traffic. If the parameters of the policy are
specified too narrowly, they will reflect the individual
implementations of QoS in each device. As there is currently
little consensus in the industry on what the correct
implementation model for QoS is, most defined attributes would
only be applicable to the unique characteristics of a few
individual devices. Lastly, standardizing all of these potential
implementation alternatives would be a never-ending task as new
implementations appear on the market.
Similarly, if the parameters of the policy are specified too
broadly, it is impossible to develop meaningful policies. For
example, if we concentrate on the so-called Olympic set of
policies, a business policy like "Bob gets Gold Service," is
clearly meaningless to the large majority of existing devices.
This is because the device has no way of determining who Bob is
or what QoS mechanisms should be configured in what way to
provide Gold service.
Furthermore, Gold service may represent a single service, or it
may portray a set of services that are related to each other. In
the latter case, these may have different conditioning
characteristics.
This draft defines a set of parameters that are fit into a
canonical model for modeling the elements in the forwarding path
of a device. By defining such a model in a device-independent
way, the needed parameters can be appropriately abstracted.
Strassner, et al. Expires: Jul 2000 + 6 months [Page 11]
Internet Draft QoS Device Info Model July 2000
3.3. Specifying Policy Services
Administrators want the flexibility to be able to define traffic
conditioning without having to have a low-level understanding of
the different QoS mechanisms that implement that conditioning.
Furthermore, administrators want the flexibility to group
different services together, so that the group of services as a
whole will receive "better" treatment than another group of
services.
These two goals dictate the need for the following set of
abstractions:
- a flexible way to describe a service
- must be able to group different services that may use
different technologies (e.g., DiffServ and 802.1P) together
- must be able to define a set of sub-services that together
make up a higher-level service
- must be able to associate a service and the set of QoS
mechanisms that are used to condition that service
- must be able to define policies that manage the QoS
mechanisms used to implement a service.
This draft addresses this set of problems by defining a set of
classes and relationships that can abstract concepts like "Gold
Service" and bind them to a specific set of QoS mechanisms that
are used to implement the conditioning required by Gold Service.
Furthermore, this draft defines the concept of "sub-services" to
enable Gold Service to be defined as a single service or a set of
services that together should be treated as an atomic entity.
Given these abstractions, policies (as defined in [QOSPIM]) can
be written to control the QoS mechanisms and services defined in
this draft.
3.4. Level of Abstraction for Defining QoS Attributes and Classes
This draft will standardize a set of classes and attributes that
are needed to support policies that configure device QoS
mechanisms. This iteration of this draft concentrates on the
representation of DiffServ services; the next iteration will
include IntServ services.
The classes and attributes in this draft are intended to be used
in conjunction with the QoS policy classes and attributes defined
in [QOSPIM]. For example, to preserve the delay characteristics
committed to the end-user, a network administrator may wish to
create policies that monitor the queue depths in a device and
Strassner, et al. Expires: Jul 2000 + 6 months [Page 12]
Internet Draft QoS Device Info Model July 2000
adjust resource allocations when delay budgets are at risk
(perhaps as a result of a network topology change). The classes
and attributes in this document define the specific services and
mechanisms required to implement those services. The classes and
attributes defined in [QOSPIM] provide the overall structure of
the policy that manages and configures this service.
This combination of low-level specification (using this draft)
and high-level structuring (using [QOSPIM]) of network services
enables network administrators to define new services required of
the network, that are directly related to business goals, while
ensuring that such services can be managed. However, this goal
(of creating and managing service-oriented policies) can only be
realized if policies can be constructed that are capable of
supporting diverse implementations of QoS. The solution is to
model the QoS capabilities of devices at the behavioral level.
This means that for DiffServ, the model must support the
following characteristics:
- Modeling of a generic network service that has QoS
capabilities
- Modeling of how DiffServ traffic conditioning is defined
- Modeling of how statistics are gathered to monitor DiffServ
(and other types of QoS) services
This draft models a network service and associates it with one or
more QoS mechanisms that are used to implement that service. It
also models the various components that are used to condition
DiffServ traffic in a canonical form, such that standard as well
as custom DiffServ services may be described. It further
generalizes this such that other technologies, such as IntServ,
may use the same set of conditioning primitives.
Statistics will be added in the next release of this draft.
3.5. Characterization of QoS Attributes
The QoS attributes and container classes will be described in
more detail in section 4. However, we should consider the basic
characteristics of these attributes to understand the methodology
for representing them.
There are essentially two types of attributes, state and
configuration. Configuration attributes describe the desired
state of the device, and include attributes and classes for
representing desired or proposed thresholds, bandwidth
allocations, and how to classify traffic. State attributes
describe the actual state of the device. This includes the
current ACTUAL value of these configuration attributes in
devices, as well as attributes that represent dynamic state
Strassner, et al. Expires: Jul 2000 + 6 months [Page 13]
Internet Draft QoS Device Info Model July 2000
(queue depths, excess capacity consumption, loss rates, and so
forth).
These two types of attributes must be modeled using a common
information model in order for them to be able to be used
together. This draft makes explicit the common information model
for modeling state as well as configuration attributes for
network QoS mechanisms. In addition, it emphasizes the need to
separate these two types of attributes.
One should note that the state attributes defined in this draft
are purposely device-independent. In contrast, configuration
attributes that are defined in a future release of this draft can
be represented and applied to either the same set of devices or a
specific device. Examples of the former are setting one or more
attributes in all devices in the same domain that share the same
AS (autonomous system) number, or all core devices that share the
same delay bound for a specific service. Examples of the latter
are setting a specific set of attributes that configures how a
device-specific implementation of a conditioning mechanism will
operate.
This difference between state and configuration attributes
suggests that the schema for configuration attributes will not be
exactly the same as the schema that supports state attributes.
However, many of the attributes defined in this draft are exactly
the settings that will be configured. Thus, the definition of
these attributes provides the link between modeling the
operational state of a device and setting configuration
parameters of that device. The intersection of these two schemata
will be through the set of attributes, associations and
aggregations that relates one schema to the other.
3.6. Identifying Common Shared Policies
Another issue that arises is how to distinguish policies for
individual devices or even components of a device from policies
that apply to a set of devices. These contextual issues depend on
more than just the policy schema in order for them to function
properly. Hence, ongoing efforts to define devices, services,
users, groups, and collections of these objects are all relevant
to the proper construction of a policy model. Context is a key
aspect of policies that still requires a great deal more work.
The next iteration of this draft will include some preliminary
results from these modeling efforts. This will focus on using the
concepts in this draft, the concepts in [QOSPIM] and some new
concepts, to establish a better definition of the context in
which a policy is operating.
Strassner, et al. Expires: Jul 2000 + 6 months [Page 14]
Internet Draft QoS Device Info Model July 2000
3.7. QoS Information Model Derivation
The question of context also begs another question: how does the
information specified in the core and QoS policy models ([PCIM]
and [QOSPIM], respectively) integrate with the information
defined in this draft? Put another way, where should device-
independent concepts that lead to device-specific QoS attributes
be derived from?
Past thinking was that QoS was part of the policy model. That is
not completely accurate, and leads to confusion. QoS is a set of
services that can be controlled using policy. These services are
represented as device mechanisms. Not all mechanisms are always
applicable for building a given service, and so this is further
abstracted by referring to the QoS capabilities of a device.
However, a key point is that QoS services, as well as other types
of services (e.g., security), are provided by the mechanisms
inherent in a given device. This means that all devices are
indeed not created equal. For example, although two devices may
have the same type of mechanism (e.g., a queue), one may be a
simple implementation (i.e., a FIFO queue) whereas one may be
much more complex and robust (i.e., CBWFQ). However, both of
these devices can be used to deliver QoS services, and both need
to be controlled by policy. Thus, a device-independent policy can
instruct the device to queue certain traffic, and a device-
specific policy can be used to implement the queuing of each
device.
Furthermore, policy is used to control these mechanisms, not to
represent them. For example, QoS services are implemented with
classifiers, meters, markers, droppers, queues, and schedulers.
Similarly, security is also a characteristic of devices, as
authentication and encryption capabilities represent services
that networked devices perform (irrespective of interactions with
policy servers). These security services may use some of the same
mechanisms that are used by QoS services, such as the concepts of
filters. However, they will largely require different mechanisms
than are used by QoS, even though they are both implemented in
the same device.
Thus, the similarity between QoS and other services is not so
much that they contain a few common mechanisms. Rather, they
model how a device implements that service. As such, the modeling
of QoS should be part of a networking device schema rather than a
policy schema. This enables the networking device schema to
concentrate on modeling device mechanisms and the policy schema
to focus on the semantics of representing the policy itself
(conditions, actions, operators, etc.). While this iteration of
this draft concentrates on defining an information model that can
represent DiffServ QoS services, the ultimate goal is to be able
to apply policies that control these services in network devices.
Furthermore, these two schemata (device and policy) must be
Strassner, et al. Expires: Jul 2000 + 6 months [Page 15]
Internet Draft QoS Device Info Model July 2000
tightly integrated in order to enable policy to control QoS
services.
3.8. Attribute Representation
The last issue to be considered is the question of how attributes
are represented. If QoS attributes are represented as absolute
numbers (e.g., Class AF2 gets 2 Mbs of bandwidth), it is more
difficult to make them uniform across multiple ports in a device
or multiple devices, because of the broad variation in link
capacities. However, expressing attributes in relative or
proportional terms (e.g., Class AF2 gets 5% of the total link
bandwidth) makes it more difficult to express certain types of
conditions and actions, such as:
(If ConsumedBandwidth = AssignedBandwidth Then ...)
There are really three alternatives to address this problem:
o Multiple attributes can be defined to express the same value
in various forms. This idea has been rejected because of the
likelihood of inconsistencies between the attributes, along
with the difficulty in keeping these different attributes
synchronized (e.g., when one attribute changes, the others all
have to be updated).
o Multi-modal attributes can be defined to express the same
value, in different terms, based on the access or assignment
mode. This option was rejected because it significantly
complicates the model and is impossible to express in current
directory access protocols (e.g., (L)DAP).
o Attributes can be expressed as "absolutes", but the operators
in the policy schema would need to be more sophisticated.
Thus, to represent a percentage, division and multiplication
operators are required (e.g., Class AF2 gets .05 * the total
link bandwidth). This is the approach that has been taken in
this draft.
3.9. Mental Model
The mental model for constructing this schema is based on the
work done in the Differentiated Services working group. This
schema is based on information provided in the current versions
of the DiffServ Conceptual Model [DSMODEL], the DiffServ MIB
[DSMIB], the PIB [PIB], as well as the set of RFCs that
constitute the basic definition of DiffServ itself ([R2475],
[R2474], [R2597], and [R2598]). In addition, a common set of
terminology is available in [POLTERM].
Note that this work is not yet completely aligned, as there are
differences between the DiffServ Conceptual Model, the DiffServ
Strassner, et al. Expires: Jul 2000 + 6 months [Page 16]
Internet Draft QoS Device Info Model July 2000
MIB, the DiffServ PIB, and this draft. Work to finish aligning
these drafts is in progress, and will be reflected in the next
revision of this draft.
This model is built around two fundamental class hierarchies that
are bound together using a set of relationships. The two class
hierarchies derive from the QoSService and ConditioningService
base classes. A set of associations relate lower-level QoSService
subclasses to higher-level QoSServices, relate different types of
ConditioningServices together in processing a traffic class, and
relate a set of ConditioningServices to a specific QoSService.
This combination of relationships enables us to view the device
as providing a set of services that can be configured, in a
modular building block fashion, to construct application-specific
services. Thus, this document can be used to model existing and
future standard as well as application-specific network QoS
services.
3.9.1. The QoSService Class
The first of these classes, QoSService, is used to represent
higher-level network services that require special conditioning
of their traffic. QoSService has a set of subclasses that
represent technology-specific implementations of QoS (e.g.,
DiffServ vs. 802.1P) as well as two relationships to the second
fundamental class, ConditioningService. This set of subclasses is
conceptualized as a set of coordinated, cooperating sub-services.
The QoS services can be related to each other or be implemented
as subservient services to each other. This enables us to define
Gold Service as (for example) a combination of the EF PHB to
implement a voice service and a set of AF PHBs to condition data
traffic. Furthermore, it lets us think of AF as a service that
requires different sub-services (e.g., a classification service,
a dropping
service, etc.) to implement it. This set of sub-services derive
from the ConditioningService class, and are related to the
QoSService class via the aggregation QoSConditioningSubServices
(see section 4 for class and relationship definitions).
This document, in its current form, identifies three subclasses
of QoS services: DiffServ, 802.1P, and Precedence. The purpose of
these subclasses is to enable administrators to manage the
application of QoS according to the specific technologies that
they are using. Thus, a network consisting of a set of DiffServ-
and non-DiffServ-compliant devices that each provided QoS traffic
conditioning would be modeled using different subclasses of
QoSService. However, each mechanism can be inter-related since
they all derive from a common base class, QoSService.
These concepts are depicted in Figure 2.
Strassner, et al. Expires: Jul 2000 + 6 months [Page 17]
Internet Draft QoS Device Info Model July 2000
/\______
0..1 \/ |
+--------------+ | QoSSubService +---------------+
| |0..n | | |
| QoSService |----- | Conditioning |
| | | Service |
| | | |
| |0..1 0..n | |
| | /\______________________| |
| | \/ QoSConditioning | |
+--------------+ SubService +---------------+
Figure 2. QoSService and its associations
3.9.2. The ConditioningService Class
The goal of the ConditioningService classes is to describe the
sequence of traffic conditioning that is applied to a given
traffic stream from an ingress to an egress interface. This is
done using a set of classes and relationships.
A single base class, ConditioningService, represents the
superclass for a set of mechanisms that condition traffic. Its
subclasses define device-independent conditioning primitives
(including classifiers, meters, markers, droppers, and queues)
that together implement the conditioning of traffic. This model
abstracts these services into a common set of modular building
blocks that can be used, regardless of device implementation, to
model the forwarding decisions internal to the device.
The different conditioning mechanisms need to be related to each
other to describe how traffic is conditioned. Several important
variations of how these services are related together exist:
- all types of ConditioningServices may not be required
- multiple instances of the same mechanism may be required
- no set order of application of each ConditioningService
exists
Therefore, this model does not dictate ordering, or a first or
last ConditioningService to be applied. Instead, this model ties
together the various ConditioningServices that can be used using
the NextService association (see Section 4). And, it allows the
special case of ingress and egress conditioning to be described
via a separate association, called ConditioningServiceOnEndpoint
(see section 4).
These concepts are depicted in Figure 3.
Strassner, et al. Expires: Jul 2000 + 6 months [Page 18]
Internet Draft QoS Device Info Model July 2000
+-------------------+
| |0..n
|ConditioningService|---------
| |0..n | NextService
| |---------
| |
0..n | |0..1 ConditioningService
----| |---------------- OnEndpoint
| +-------------------+ |
| |
|NextServiceAfterMeter |
| |0..1
|0..n +---------+ +------------------+
-----| Meter | | ProtocolEndpoint |
+---------+ +------------------+
Figure 3. ConditioningService and its associations
3.9.3. QoS Statistics Classes
Various statistics classes were proposed in the previous
iteration of this draft. Such statistics are necessary to
properly instrument QoS services. However, since the core of this
draft has been reworked, the previous statistics classes did not
correspond and were removed. The next iteration of this draft
will add these classes back into the draft.
4. The Class Hierarchy
The following sections describe the class hierarchy of the
information model for modeling QoS capabilities at the device
level.
4.1. Difference Between Inheritance and Relationship Associations
This draft defines two different sets of associations -
inheritance and class relationships (such as dependencies and
aggregations). Inheritance hierarchies are "the mechanism by
which more-specific elements incorporate the structure and
behavior of more-general elements." [UMLUG] The next two sections
describe the class relationships that are used in this draft and
model.
4.1.1. Associations
An association is a means of representing a dependency
relationship between two (or theoretically more) objects. In CIM
and DEN, this type of relationship is modeled as a class
containing two (or more) object references. Since the
association is itself a class, it can benefit from all of the
Strassner, et al. Expires: Jul 2000 + 6 months [Page 19]
Internet Draft QoS Device Info Model July 2000
object-oriented abilities that other non-association classes
have. For example, it can contain properties and methods, and
inheritance can be used to refine its semantics such that it
represents a more specialized type of dependency. This has proven
to be a very useful abstraction, and will be used in this
document as well.
It is important to note that associations form a hierarchy that
is separate from the inheritance hierarchy. Although associations
are inherently bi-directional, there is nothing that prevents
higher order associations from being defined. However, such
associations are inherently more complex to define, understand
and use. In practice, associations higher than binary are rarely
used because of their greatly increased complexity and lack of
generality.
Finally, note that associations that are defined between two
classes do not affect the classes themselves. That is, the
addition or deletion of an association does not affect the
interface of the classes that it is connecting.
4.1.2. Aggregations
An aggregation is a strong form of an association, which usually
represents a "whole-part" or a "collection" relationship. For
example, CIM uses an aggregation to represent the containment
relationship between a system and the components that make it up.
In this draft, all aggregations represent "whole-part"
relationships.
Note that an aggregate object is treated as an atomic unit, even
though it is comprised of, or collects, multiple objects. This is
a defining feature of an aggregation -
- although the individual
components that make up an aggregate object have their own
identities, the aggregate object that is constructed from these
objects has its own identity and name.
"Whole-part" aggregations have some very interesting properties:
- cascaded deletion (if you delete the aggregate, you delete
all of its constituent components)
- transitivity (e.g., if Object A is-a-part-of Object B, and
if Object B is-a-part-of Object C, then Object A is-a-
part-of Object C)
- anti-symmetricity (e.g., if Object A is-a-part-of Object B,
then Object B can not also be a-part-of Object A)
Aggregation is used to represent the physical and/or logical
grouping of related objects.
Strassner, et al. Expires: Jul 2000 + 6 months [Page 20]
Internet Draft QoS Device Info Model July 2000
4.2. The Structure of the Class Hierarchy
The following sections discuss the class hierarchies that will be
used to model the state of QoS devices and services. A later
release will include configuration hierarchies. This model is
influenced by [CIM], and is compatible with the Directory Enabled
Networks (DEN) effort.
4.2.1. The Class Hierarchy for Modeling State Information
The structure of the Class Hierarchy for managing the state of
Differentiated and Integrated Services is shown in Figure 4. In
this figure, the following definitions apply:
- CIMCORE: a class that is defined in the CIM Core Model
- CIMNET: a class that is defined in the CIM Network Model
All of the remaining classes are defined in this document. Please
refer to [CIM] for the definitions of the classes in [CIMCORE]
and [CIMNET].
Strassner, et al. Expires: Jul 2000 + 6 months [Page 21]
Internet Draft QoS Device Info Model July 2000
+--ManagedElement (defined in [CIMCORE])
|
+--ManagedSystemElement (defined in [CIMCORE])
| |
| +--LogicalElement (defined in [CIMCORE])
| | |
| | +--Service (defined in [CIMCORE])
| | | |
| | | +--NetworkService (defined in [CIMNET])
| | | | |
| | | | +--ForwardingService (defined in [CIMNET])
| | | | | |
| | | | | +--ConditioningService
| | | | | | |
| | | | | | +--ClassifierService
| | | | | | |
| | | | | | +--MeterService
| | | | | | | |
| | | | | | | +--AverageRateMeter
| | | | | | | |
| | | | | | | +--EWMAMeter
| | | | | | | |
| | | | | | | +--TokenBucketMeter
| | | | | | |
| | | | | | +--MarkerService
| | | | | | |
| | | | | | +--DropperService
| | | | | | | |
| | | | | | | +--RedDropper
| | | | | | | | |
| | | | | | | | +--WeightedRedDropper
| | | | | | |
| | | | | | +--QueuingService
| | | | | |
| | | | | +--PacketSchedulingService
| | | | | | |
| | | | | | +--PrioritySchedulingService
| | | | | | | |
| | | | | | | +--PriorityBandwidth
| | | | | | | SchedulingService
| | | | | | |
| | | | | | +--BandwidthSchedulingService
| | | | | | |
| | | | | | +--RoundRobinPacketSchedulingService
| | | | | | | |
| | | | | | | +--WeightedRoundRobinPacket
SchedulingService
(continued on following page)
Strassner, et al. Expires: Jul 2000 + 6 months [Page 22]
Internet Draft QoS Device Info Model July 2000
(continued from previous page,
first four elements are repeated for convenience)
+--ManagedElement (defined in [CIMCORE])
|
+--ManagedSystemElement (defined in [CIMCORE])
| |
| +--LogicalElement (defined in [CIMCORE])
| | |
| | +--Service (defined in [CIMCORE])
| | | |
| | | +--NetworkService (defined in [CIMNET])
| | | | |
| | | | +--ForwardingService (defined in [CIMNET])
| | | | | |
| | | | +--QoSService
| | | | | |
| | | | | +--DiffServService
| | | | | | |
| | | | | | +--AFService
| | | | | | |
| | | | | | +--EFService
| | | | | |
| | | | | +--PrecedenceService
| | | | | |
| | | | | +--8021PService
| | |
| | +--FilterEntryBase (defined in [CIMNET])
| | | |
| | | +--FilterEntry (defined in [CIMNET])
| | |
| | +--FilterList (defined in [CIMNET])
| | |
| | +--ServiceAccessPoint (defined in [CIMCORE])
| | | |
| | | +--ProtocolEndpoint (defined in [CIMNET])
|
+--Collection (defined in [CIMCORE])
| |
| +--CollectionOfMSEs (defined in [CIMCORE])
| | |
| | +--BufferPool
Figure 4. Inheritance Class Hierarchy
The set of associations and aggregations defined in this draft
are shown in Figure 5.
Strassner, et al. Expires: Jul 2000 + 6 months [Page 23]
Internet Draft QoS Device Info Model July 2000
+--Dependency
| |
| +--ServiceSAPDependency
| | |
| | +--ConditioningServiceOnEndpoint
| | |
| +--ServiceServiceDependency
| | |
| | +--QueueHierarchy
| | |
| | +--SchedulerUsed
| | |
| +--QueueAllocation
| |
| +--ClassifierFilterSet
|
+--AFRelatedServices
|
+--NextService
| |
| +--NextServiceAfterMeter
|
+--MemberOfCollection
| |
| +--CollectedBufferPool
|
+--Component
| |
| +--ServiceComponent
| | |
| | +--QoSSubService
| | |
| | +--QoSConditioningSubService
| |
| +--EntriesInFilterList
Figure 5. Relationship Class Hierarchy
4.2.2. The Class Hierarchy for Modeling Configuration Information
The structure of the class hierarchy for managing the
configuration of Differentiated and Integrated Services will be
presented in the next iteration of this draft. This is due to the
above hierarchy being changed significantly to reflect
participant feedback.
4.3. Class Definitions for the State Portion of the Model
This section will define the classes and attributes that make up
the Information Model for describing the QoS-related
functionality of network devices. This information is derived
from the CIM Network Model [CIM]. Only new classes that are
Strassner, et al. Expires: Jul 2000 + 6 months [Page 24]
Internet Draft QoS Device Info Model July 2000
presented in this draft will be defined; however, all existing
Network Model classes will be described briefly. The reader is
encouraged to look at [CIM] for further information. Associations
and aggregations will be defined in Section 4.3.
4.3.1. The Class ManagedElement
This is an abstract class that is defined in the Core Model of
CIM. It is the root of the entire CIM inheritance hierarchy and
exists as a referenced class in some generic associations, such
as Dependency and MemberOfCollection. ManagedElement's
properties are Caption and Description. Both are free-form
strings to describe an instantiated object. Please refer to [CIM]
for the full definition of this class.
4.3.2. The Class ManagedSystemElement
This is an abstract class that is defined in the Core Model of
CIM. It is the base class of the System, Physical, and Logical
Element class hierarchies. Any distinguishable component of a
System is a candidate for inclusion in this class hierarchy,
including physical components (e.g., chips and cards) and logical
components (e.g., software components, services, and other
objects). Please refer to [CIM] for the full definition of this
class.
4.3.3. The Class LogicalElement
This is an abstract class that is defined in the Core Model of
CIM. It is a subclass of the ManagedSystemElement class, and is
the base class for all components of a managed System, such as
Files, Processes, or system capabilities in the form of Logical
Devices and Services. Please refer to [CIM] for the full
definition of this class.
4.3.4. The Class Service
This is an abstract class that is defined in the Core Model of
CIM. It is a subclass of the LogicalElement class, and is the
base class for all objects which provide a "service" or
functionality in a System. Note that a Service is a general-
purpose object that is used to configure and manage the
implementation of functionality. Please refer to [CIM] for the
full definition of this class.
4.3.5. The Class NetworkService
This is an abstract class that is defined in the Network Common
Model of CIM. It is a subclass of the Service class, and is the
base class rooting the network service hierarchy. Network
services represent generic functions that are available from the
network, and that condition and/or modify one or more parameters
Strassner, et al. Expires: Jul 2000 + 6 months [Page 25]
Internet Draft QoS Device Info Model July 2000
of the traffic being sent, such as fields in a packet's header.
Please refer to [CIM] for the full definition of this class.
4.3.6. The Class ForwardingService
This is a concrete class that is defined in the Network Common
Model of CIM. It is a subclass of the NetworkService class, and
represents the forwarding of network traffic by receiving data
from one or more communication sources, and discarding it or
sending it via other communication sources. The properties of
ForwardingService are ProtocolType and OtherProtocolType -
describing the type of protocol being forwarded. Please refer to
[CIM] for the full definition of this class.
4.3.7. The Class ConditioningService
This class is a specialization of ForwardingService, and
represents the ability to define how traffic is conditioned in
the data forwarding path of a device. The subclasses of
ConditioningService define the particular type of conditioning
that is done. Five fundamental types of functions are defined in
this draft. They are the services performed by a classifier,
meter, marker, dropper, and queue. Note that other, more
sophisticated, types of conditioning may be defined in future
iterations.
Two associations of ConditioningService are critical to its usage
in QoS - QoSConditioningSubService and NextService.
QoSConditioningSubService aggregates ConditioningServices into a
particular QoS service (such as AF) to describe the specific
conditioning functionality that underlies that QoS service.
NextService indicates the subsequent conditioning service(s) for
different traffic streams.
The class definition is as follows:
NAME ConditioningService
DESCRIPTION A concrete class to define how traffic
will be conditioned in the data
forwarding path of a network device.
DERIVED FROM ForwardingService
TYPE Structural
PROPERTIES Enabled
4.3.7.1. The property Enabled
This property is a boolean that, if TRUE, signifies that one or
more conditioning functions can be performed on traffic
encountered by the ConditioningService.
Strassner, et al. Expires: Jul 2000 + 6 months [Page 26]
Internet Draft QoS Device Info Model July 2000
4.3.8. The Class ClassifierService
This is a new concrete class that is defined in this model. The
concept of a Classifier is defined in [DSMODEL]. It represents a
logical entity in the data forwarding path of a device, that
takes a single input stream and sorts into one or more output
streams. The sorting is done by a set of filters that select
packets based on the packet contents (or possibly other
attributes associated with the packet). Each output stream is the
result of matching a particular filter (or not matching any
filter).
This version of this model does not generalize the representation
of a classifier. Rather, it seeks to portray a classifier as
defined by [DSMODEL]. Thus, the principal components of a
classifier are its ability to use filters. The association,
ClassifierFilterSet, conveys this basic semantic.
A Classifier is modeled as a ConditioningService so that it can
be aggregated into a QoSService (using the
QoSConditioningSubService association), and can use the
NextService association to describe the subsequent
ConditioningServices for different traffic streams.
The class definition is as follows:
NAME ClassifierService
DESCRIPTION A concrete class describing how an input
traffic stream is sorted into multiple
output streams using one or more
filters.
DERIVED FROM ConditioningService
TYPE Structural
PROPERTIES ClassifierType, OtherClassifierType,
HaveClassifiedPackets
4.3.8.1. The Property ClassifierType
This is an enumerated 16-bit unsigned integer that is used to
define the specific type of classifier of this instance. The
following types of classifiers are defined in this draft (please
see [DSMODEL] for a description of each one):
1 - Other
2 - Behavior Aggregate
3 - IPv4 Multi-Field-5
4 - IPv6 Multi-Field-5
5 - IPv4 Multi-Field-6
6 - IPv6 Multi-Field-6
7 - 802 MAC
8 - IEEE Priority
9 - IEEE VLAN
Strassner, et al. Expires: Jul 2000 + 6 months [Page 27]
Internet Draft QoS Device Info Model July 2000
10 - Free-form
Here, Multi-Field-5 defines a filter to match on source and
destination IP address, source and destination port, and IP
Protocol. Multi-Field-6 is the same, except that the DSCP value
is also matched.
4.3.8.2. The Property OtherClassifierType
This is a string attribute that defines a vendor-specific
description of the type of classifier. It is used when the value
of the ClassifierType attribute of this class is equal to 1.
4.3.8.3. The Property HaveClassifiedPackets
This is a Boolean attribute that, if TRUE, means that this
Classifier has already processed at least one packet.
4.3.9. The Class MeterService
This is a new concrete class, defined in this model. This class
represents the metering of network traffic. Metering is the
function of monitoring the arrival times of packets of a traffic
stream and determining the level of conformance of each packet
with respect to a pre-established traffic profile. A meter has
the ability to invoke different ConditioningServices for
conforming and non-conforming traffic. Non-conforming packets may
be further conditioned (e.g., dropped or queued) by routing the
packet to another conditioning element. Please see [DSMODEL] for
more information on metering.
This class is the base class for defining different types of
meters. As such, it contains common properties that all meter
subclasses share. It is modeled as a ConditioningService so that
it can be aggregated into a QoSService (using the
QoSConditioningSubService association) to describe that its
functionality underlies that QoS service. Also, it uses a
subclass of the NextService association to describe the
subsequent ConditioningServices for conforming and non-conforming
traffic.
The class definition is as follows:
NAME MeterService
DESCRIPTION A concrete class describing the
monitoring of traffic with respect to a
pre-established traffic profile.
DERIVED FROM ConditioningService
TYPE Structural
PROPERTIES MeterType, OtherMeterType,
ConformanceLevels
Strassner, et al. Expires: Jul 2000 + 6 months [Page 28]
Internet Draft QoS Device Info Model July 2000
Note: The MeterType property and the MeterService subclasses
provide similar information. The MeterType property is defined
for query purposes and for future expansion. It is assumed that
not all MeterServices will require a subclass to define them.
Therefore, MeterService will be instantiated directly and the
Type property is needed.
4.3.9.1. The Property MeterType
This attribute is an enumerated 16-bit unsigned integer that is
used to specify the particular type of meter that is being used.
Defined values of the enumerations are:
1 - Other
2 - Average Rate Meter
3 - Exponentially Weighted Moving Average Meter
4 - TokenBucketMeter
4.3.9.2. The Property OtherMeterType
This is a string attribute that defines a vendor-specific
description of the type of meter. It is used when the value of
the MeterType attribute of this class is equal to 1.
4.3.9.3. The Property ConformanceLevels
This attribute is a 16-bit unsigned integer. It indicates the
number of conformance levels supported by the meter. For
example, when only "in-profile" or "out of profile" metering is
supported, ConformanceLevels is set to 2.
4.3.10. The Class AverageRateMeter
This is a new concrete class, defined in this model. It is a
subclass of MeterService and describes a simple meter, called an
Average Rate Meter. This type of meter measures the average rate
at which packets are submitted to it over a specified time.
Packets are defined as conformant if their average arrival rate
does not exceed the specified measuring rate of the meter. Any
packet that causes the specified measuring rate to be exceeded is
defined to be non-conforming. For more information, please see
[DSMODEL].
The class definition is as follows:
NAME AverageRateMeter
DESCRIPTION A concrete class describing traffic as
either conforming or non-conforming,
depending on whether the arrival of a
packet causes the average arrival rate
to exceed a pre-determined value or not.
DERIVED FROM MeterService
Strassner, et al. Expires: Jul 2000 + 6 months [Page 29]
Internet Draft QoS Device Info Model July 2000
TYPE Structural
PROPERTIES AverageRate, DeltaInterval
4.3.10.1. The Property AverageRate
This is a 32-bit real number that defines the rate that is used
to determine whether admitted packets are in conformance or not.
The value is specified in kilobits per second.
4.3.10.2. The Property DeltaInterval
This is a 32-bit real number that defines the time period over
which the average measurement should be taken. The value is
specified in microseconds.
4.3.11. The Class EWMAMeter
This is a new concrete class, defined in this model. It is a
subclass of the MeterService class, and represents an
exponentially weighted moving average meter. This meter is a
simple IIR low-pass filter that measures the rate of incoming
packets over a small, fixed sampling interval. Any admitted
packet that pushes the average rate over a pre-defined limit is
defined to be non-conforming. Please see [DSMODEL] for more
information.
The class definition is as follows:
NAME EWMAMeter
DESCRIPTION A concrete class describing admitted
traffic as either conforming or non-
conforming, depending on whether the
arrival of a packet in a small fixed
sampling interval causes the average
arrival rate to exceed a
pre-determined value or not.
DERIVED FROM MeterService
TYPE Structural
PROPERTIES AverageRate, DeltaInterval, Gain
4.3.11.1. The Property AverageRate
This attribute is a 32-bit real number that defines the average
rate against which the sampled arrival rate of packets should be
measured. Any packet that causes the sampled rate to exceed this
rate is deemed non-conforming. The value is specified in kilobits
per second.
4.3.11.2. The Property DeltaInterval
This attribute is a 32-bit real number that defines the sampling
interval used to measure the arrival rate in bytes. The
Strassner, et al. Expires: Jul 2000 + 6 months [Page 30]
Internet Draft QoS Device Info Model July 2000
calculated rate is averaged over this interval and checked
against the AverageRate attribute. All packets whose computed
average arrival rate is less than the AverageRate are deemed
conforming.
The value is specified in microseconds.
4.3.11.3. The Property Gain
This attribute is a 32-bit real number that defines the time
constant (e.g., frequency response) of what is essentially a
simple IIR low-pass filter.
4.3.12. The Class TokenBucketMeter
This is a new concrete class that is defined in this model. It
describes the metering of network traffic using a token bucket
meter. Two types of token bucket meters are defined using this
class - a simple, two parameter bucket meter, and a multi-stage
meter.
A simple token bucket usually has two parameters, an average
token rate and a burst size, and has two conformance levels. This
class also defines an excess burst size, which enables the meter
to have three conformance levels (basically, "conforming",
"partially conforming", and "non-conforming"). The difference is
that packets that exceed the excess burst size are deemed non-
conforming, while packets that exceed the smaller BurstSize but
are less than the ExcessBurst size are deemed partially
conforming. Operation of these meters is described in [DSMODEL].
The class definition is as follows:
NAME TokenBucketMeter
DESCRIPTION A concrete class describing admitted
traffic with respect to a token bucket.
Either two or three levels of
Conformance can be defined.
DERIVED FROM MeterService
TYPE Structural
PROPERTIES AverageRate, PeakRate,
BurstSize, ExcessBurstSize
4.3.12.1. The Property AverageRate
This attribute is a 32-bit real number that is used to define the
committed rate of the meter. The value is specified in kilobits
per second.
Strassner, et al. Expires: Jul 2000 + 6 months [Page 31]
Internet Draft QoS Device Info Model July 2000
4.3.12.2. The Property PeakRate
This attribute is a 32-bit real number that is used to define the
peak rate of the meter. The value is specified in kilobits per
second.
4.3.12.3. The Property BurstSize
This attribute is a 32-bit real number that is used to define the
maximum number of tokens available for the committed rate
(specified by the AverageRate property). The value is specified
in kilobytes.
4.3.12.4. The Property ExcessBurstSize
This attribute is a 32-bit real number that is used to define the
maximum number of tokens available for the peak rate (specified
by the PeakRate property). The value is specified in kilobytes.
4.3.13. The Class MarkerService
This is a new concrete class, defined in this model. It describes
the marking or re-marking (e.g., setting or resetting of a
particular field in a packet header) of network traffic. Markers
may act either on unmarked packets or re-mark previously marked
ones. Markers are usually invoked as a result of a preceding
classifier match. Operation of various types of markers is
described in [DSMODEL].
MarkerService is modeled as a ConditioningService so that it can
be aggregated into a QoSService (using the
QoSConditioningSubService association) to describe that its
functionality underlies that QoS service. Also, it uses the
NextService association to describe the subsequent
ConditioningServices after marking.
The class definition is as follows:
NAME MarkerService
DESCRIPTION A concrete class defining the value of a
field in a packet that is "marked" in
order to control the conditioning that
the packet receives.
DERIVED FROM ConditioningService
TYPE Structural
PROPERTIES CanRemark, RemarkType, OtherRemarkType,
RemarkValue
4.3.13.1. The Property CanRemark
This is a boolean attribute that, when TRUE, signifies that this
Marker can remark the field value specified in the RemarkType
Strassner, et al. Expires: Jul 2000 + 6 months [Page 32]
Internet Draft QoS Device Info Model July 2000
attribute with the value specified in the RemarkValue attribute.
The change will be made to unmarked packets and to remark a
previously marked one.
Otherwise, if FALSE and the field value is filled in, then NO
remarking will be done. If FALSE, only unmarked packets will be
changed.
4.3.13.2. The Property RemarkType
This attribute is an enumerated 16-bit unsigned integer that
defines what type of remarking will be done. Values include:
1 - Other
2 - Mark ToS Byte
3 - Mark the DSCP
4 - Mark the Priority Field
4.3.13.3. The Property OtherRemarkType
This is a string attribute that defines a vendor-specific
description of the type of remarking that is done. It is used
when the value of the RemarkType attribute of this class is equal
to 1.
4.3.13.4. The Property RemarkValue
This attribute is a 16-bit unsigned integer that is the value to
be applied to the field specified in the RemarkType attribute.
4.3.14. The Class DropperService
This is a new concrete class, defined in this model. It
represents the ability to drop network traffic or invoke another
ConditioningService for further processing of the remaining
traffic. This is the base class for different types of droppers.
Droppers are distinguished by the algorithm that they use to drop
traffic. Please see [DSMODEL] for more information about the
various types of droppers.
DropperService is modeled as a ConditioningService so that it can
be aggregated into a QoSService (using the
QoSConditioningSubService association) to describe that its
functionality underlies that QoS service. Also, it uses the
NextService association to describe the subsequent
ConditioningServices for further processing of any remaining
traffic.
The class definition is as follows:
Strassner, et al. Expires: Jul 2000 + 6 months [Page 33]
Internet Draft QoS Device Info Model July 2000
NAME DropperService
DESCRIPTION A concrete base class describing the
common characteristics of droppers.
DERIVED FROM ConditioningService
TYPE Structural
PROPERTIES DropperType, OtherDropperType,
AlwaysDrop, DropStartMetric,
DropMaintainMetric
Note: The DropperType property and the DropperService subclasses
provide similar information. The DropperType property is defined
for query purposes and to not require a subclass for all types of
DropperServices (for example, to describe a Head or Tail dropper
in today's model). Therefore, DropperService can be instantiated
directly and the Type property is needed.
4.3.14.1. The Property DropperType
This is an enumerated 16-bit unsigned integer that defines the
type of dropper. Values are:
1 - Other
2 - Head
3 - Tail
4 - RED
5 - Weighted RED
4.3.14.2. The Property OtherDropperType
This string attribute is used in conjunction with the DropperType
attribute. When the value of DropperType is 1 (e.g., Other), then
the name of the type of dropper (for this instance) is defined in
this attribute.
4.3.14.3. The Property AlwaysDrop
This is a boolean attribute that, if TRUE, signifies that this
Dropper will always drop incoming packets.
4.3.14.4. The Property DropStartMetric
This property is an enumerated 16-bit unsigned integer that
defines the metric used to trigger the start of dropping packets.
This does NOT mean that all packets will be dropped; it does mean
that SOME packets will start to be dropped. The number and type
of packets dropped is a function of the type of algorithm used by
this Dropper.
Values are:
1 - Other
2 - Queue Threshold
Strassner, et al. Expires: Jul 2000 + 6 months [Page 34]
Internet Draft QoS Device Info Model July 2000
3 - Arrival Rate
4.3.14.5. The Property DropMaintainMetric
This property is an enumerated 16-bit unsigned integer that
defines the metric used to determine when ALL packets will be
dropped regardless of the type of algorithm used by this Dropper.
Values are:
1 - Other
2 - Queue Threshold
3 - Arrival Rate
4.3.15. The Class REDDropperService
This is a new concrete class, defined in this model. It describes
the ability to drop network traffic using a Random Early
Detection (RED) algorithm. This algorithm is described in [RED].
REDÆs purpose is congestion avoidance (as opposed to managing
congestion). Instead of waiting for the queues to fill up and
then dropping large numbers of packets, RED works by monitoring
the average queue depth. When the queue depth exceeds a minimum
threshold, packets are randomly discarded, asking only those
connections to slow down. Please see [DSMODEL] for more
information about a dropper.
The class definition is as follows:
NAME REDDropperService
DESCRIPTION A concrete class used to describe
Dropping using the RED algorithm (or
one of its variants).
DERIVED FROM DropperService
TYPE Structural
PROPERTIES MinQueueThreshold, MaxQueueThreshold,
StartProbability, StopProbability
4.3.15.1. The Property MinQueueThreshold
This is a 32-bit real number, and is used to define the minimum
queue length at which packets are subject to being dropped.
4.3.15.2. The Property MaxQueueThreshold
This is a 32-bit real number, and is used to define the maximum
queue length at which packets will always be dropped.
4.3.15.3. The Property StartProbability
This is a 32-bit real number, and is used in conjunction with the
StopProbability attribute to define the slope of the drop
Strassner, et al. Expires: Jul 2000 + 6 months [Page 35]
Internet Draft QoS Device Info Model July 2000
probability function. The latter governs the rate at which
packets are subject to being dropped, as a function of the queue
length.
Min and max values are 0 to 100.
4.3.15.4. The Property StopProbability
This is a 32-bit real number, and is used in conjunction with the
StartProbability attribute to define the slope of the drop
probability function. The latter governs the rate at which
packets are subject to being dropped, as a function of the queue
length.
Min and max values are 0 to 100.
4.3.16. The Class WeightedREDDropperService
This is a new concrete class, defined in this model. It describes
the ability to drop network traffic using a Weighted Random Early
Detection (WRED) algorithm. Like RED, the purpose of WRED is to
avoid congestion (as opposed to managing congestion). This
modification of the basic RED algorithm enables packets belonging
to different traffic classes to be dropped at different queue
depths. This algorithm also enables discard to be done based on
different information contained in the packet header, such as IP
Precedence, RSVP session parameters, or even on other factors not
directly encoded in the packet header, such as the queue depth.
Please see [DSMODEL] for more information about a dropper.
The class definition is as follows:
NAME WeightedREDDropperService
DESCRIPTION A concrete class used to describe
Dropping using the weighted
RED algorithm.
DERIVED FROM REDDropperService
TYPE Structural
PROPERTIES DropMetric, OtherDropMetric, Weight
4.3.16.1. The Property DropMetric
This attribute is an enumerated 16-bit unsigned integer, and
defines the type of metric that is used to drop traffic. Values
are:
1 - Other
2 - IP Precedence
3 - DSCP Value
4 - 802.1P Priority Value
5 - RSVP Session
6 - Queue Depth
Strassner, et al. Expires: Jul 2000 + 6 months [Page 36]
Internet Draft QoS Device Info Model July 2000
7 - Packet Arrival Rate
4.3.16.2. The Property OtherDropMetric
This string attribute is used in conjunction with the DropMetric
attribute. When the value of DropMetric is 1 (e.g., Other), then
the type of metric is defined in this attribute.
4.3.16.3. The Property Weight
This is a 32-bit real number that representing the weighting
factor used to used to determine which queues get more service.
Min and max values are 0 to 100.
4.3.17. The Class QueuingService
This is a new concrete class that is defined in this model. It
represents the ability to queue network traffic and to specify
the characteristics for determining long-term congestion. Please
see [DSMODEL] for more information about queuing functionality.
QueuingService is modeled as a ConditioningService so that it can
be aggregated into a QoSService (using the
QoSConditioningSubService association) to describe that its
functionality underlies that QoS service. Also, it uses the
NextService association to describe if there are any subsequent
ConditioningServices.
The class definition is as follows:
NAME QueuingService
DESCRIPTION A concrete class describing the ability
to queue network traffic and to specify
the characteristics for determining
long-term congestion.
DERIVED FROM ConditioningService
TYPE Structural
PROPERTIES SmoothingWeight, TimeInterval,
GiveExcessCapacity
4.3.17.1. The Property SmoothingWeight
This attribute is a 32-bit real number, and defines the degree to
which each actual queue depth influences the averaged (smoothed)
queue depth used for determining long-term congestion in RED-like
droppers. This attribute is specified as the percentage/weight
that each calculation of averaged queue depth influences the new
value of average depth.
Min and max values are 0 to 100.
Strassner, et al. Expires: Jul 2000 + 6 months [Page 37]
Internet Draft QoS Device Info Model July 2000
4.3.17.2. The Property TimeInterval
This attribute is a 32-bit unsigned integer, and defines the
number of nano-seconds between each calculation of average queue
depth. When this attribute is not specified, it implies that the
calculation is performed every time a packet departs from the
queue under normal operating conditions. In other words, if the
queue is serviced intermittently, the calculations will be
performed logically to simulate a consistent queue servicing
interval.
4.3.17.3. The Property GiveExcessCapacity
This property is a boolean attribute that, if TRUE, enables the
queue to be made available to other queue/scheduler instances.
When true, the queue can be used to hold packets from other
traffic classes than normally serviced. For example, assume that
queues for Gold, Silver and Bronze traffic classes are defined.
Further assume that the Silver queue is full and the others are
empty. If this boolean is set for the Gold and Bronze queues,
their capacity can be used to hold Silver traffic, as opposed to
dropping it.
4.3.18. The Class PacketSchedulingService
This is a new concrete class that is defined in this model. It
represents a scheduling service, which is a process that
determines whether a queued packet should be removed from a queue
and sent to an output interface. Note that output interfaces can
be physical network interfaces or interfaces to components
internal to systems, such as crossbars or backplanes. In either
case, if multiple queues are involved, schedulers are used to
provide access to the interface.
Each instance of a PacketSchedulingService describes a scheduler
from the perspective of the queue that it is servicing. One can
describe that different schedulers support different queues, or
that a scheduler supports several queues. Please see [DSMODEL]
for more information about a scheduler.
PacketSchedulingService is modeled as a sibling service to
ConditioningService. Both are derived from a common root,
ForwardingService.
The class definition is as follows:
NAME PacketSchedulingService
DESCRIPTION A concrete class used to determine if an
arriving packet should be stored in a
queue or not.
DERIVED FROM ForwardingService
TYPE Structural
Strassner, et al. Expires: Jul 2000 + 6 months [Page 38]
Internet Draft QoS Device Info Model July 2000
PROPERTIES SchedulerType, OtherSchedulerType
Note: The SchedulerType property and the SchedulerService
subclasses provide similar information. The SchedulerType
property is defined for query purposes and to not require a
subclass for all types of SchedulerServices (for example, to
describe a FIFO scheduler in today's model). Therefore,
SchedulerService can be instantiated directly and the Type
property is needed.
4.3.18.1. The Property SchedulerType
This attribute is an enumerated 16-bit unsigned integer, and
defines the type of scheduler. Values are:
1 - Other
2 - FIFO
3 - Priority
4 - Bandwidth
5 - Priority Bandwidth
6 - Round Robin Packet
7 - Weighted Round Robin Packet
4.3.18.2. The Property OtherSchedulerType
This attribute is used in conjunction with the SchedulerType
attribute. When the value of SchedulerType is 1 (e.g., Other),
then the type of scheduler is defined in this attribute.
4.3.19. The Class PrioritySchedulingService
This is a new concrete class, defined in this model. It
represents a simple priority scheduler, which is a process that
schedules taking packets from different priority queues. Please
see [DSMODEL] for more information about a scheduler.
The class definition is as follows:
NAME PrioritySchedulingService
DESCRIPTION A concrete class used to represent a
simple priority scheduling service.
DERIVED FROM PacketSchedulingService
TYPE Structural
PROPERTIES Priority
4.3.19.1. The Property Priority
This property is a 16-bit unsigned integer that defines the
priority level of the queue that is being scheduled.
Strassner, et al. Expires: Jul 2000 + 6 months [Page 39]
Internet Draft QoS Device Info Model July 2000
4.3.20. The Class PriorityBandwidthSchedulingService
This is a new concrete class, defined in this model. It
represents a priority scheduler that is extended to specify an
upper limit on the bandwidth that can be sent on the priority
queue over some time interval. Please see [DSMODEL] for more
information about a scheduler.
The class definition is as follows:
NAME PriorityBandwidthSchedulingService
DESCRIPTION This class represents a priority
scheduler that is extended to specify
an upper limit on the bandwidth that
can be sent on the priority
queue over some time interval.
DERIVED FROM PrioritySchedulingService
TYPE Structural
PROPERTIES BandwidthAllocation, BurstsAllowed,
BurstAllocation
4.3.20.1. The Property BandwidthAllocation
This attribute is a 32-bit unsigned integer, and defines the
number of bytes that can be delivered from a queue each cycle.
4.3.20.2. The Property BurstsAllowed
This is a boolean attribute which, if TRUE, signifies that a
temporary or short-term allocation of additional bandwidth in
addition to the amount of bandwidth allocated through the
BandwidthAllocation property is allowed.
4.3.20.3. The Property BurstAllocation
This attribute is a 32-bit unsigned integer, and specifies the
amount of temporary or short-term bandwidth that can be allocated
beyond the amount of bandwidth allocated through the
BandwidthAllocation property. If the maximum actual bandwidth
allocation were to be measured, it would be the sum of the
BurstAllocation and the BandwidthAllocation properties.
4.3.21. The Class BandwidthSchedulingService
This is a new concrete class, defined in this model. It
represents a bandwidth scheduler, which is a process that
reserves a portion of the bandwidth of a link for each selected
traffic type.
The class definition is as follows:
NAME BandwidthSchedulingService
Strassner, et al. Expires: Jul 2000 + 6 months [Page 40]
Internet Draft QoS Device Info Model July 2000
DESCRIPTION A concrete class used to represent
a simple bandwidth scheduling service.
DERIVED FROM PacketSchedulingService
TYPE Structural
PROPERTIES BandwidthAllocation, BurstsAllowed,
BurstAllocation, CanShare,
WorkConserving
4.3.21.1. The Property BandwidthAllocation
This attribute is a 32-bit unsigned integer, and defines the
number of bytes that can be delivered from a queue each cycle.
4.3.21.2. The Property BurstsAllowed
This is a boolean attribute which, if TRUE, signifies that a
temporary or short-term allocation of additional bandwidth in
addition to the amount of bandwidth allocated through the
BandwidthAllocation property is allowed.
4.3.21.3. The Property BurstAllocation
This attribute is a 32-bit unsigned integer, and specifies the
amount of temporary or short-term bandwidth that can be allocated
beyond the amount of bandwidth allocated through the
BandwidthAllocation property. If the maximum actual bandwidth
allocation were to be measured, it would be the sum of the
BurstAllocation and the BandwidthAllocation properties.
4.3.21.4. The Property CanShare
This is a boolean attribute that, if TRUE, enables unused
bandwidth from the associated queue to be allocated to queues
that need additional resources.
4.3.21.5. The Property WorkConserving
This is a boolean attribute that, if TRUE, prevents the scheduler
from bursting traffic from the queue to which this instance of
the scheduler is associated (via SchedulerUsed). When TRUE, this
attribute also prevents bandwidth from other idle queues to be
consumed by the current queue, thereby preventing resource
allocations above the assigned bandwidth.
4.3.22. The Class RoundRobinPacketSchedulingService
This is a new concrete class, defined in this model. It
represents a round robin packet scheduler, which is a process
that guarantees that bandwidth will be allocated fairly at the
packet level. With this type of scheduler, each queue is entitled
to equal access to the output interface.
Strassner, et al. Expires: Jul 2000 + 6 months [Page 41]
Internet Draft QoS Device Info Model July 2000
The class definition is as follows:
NAME RoundRobinPacketSchedulingService
DESCRIPTION A concrete class used to represent a
scheduler that fairly allocates packet
transmission among its traffic classes.
DERIVED FROM PacketSchedulingService
TYPE Structural
PROPERTIES None
4.3.23. The Class WeightedRoundRobinPacketSchedulingService
This is a new concrete class, defined in this model. It
represents a weighted packet scheduler, which is the same as a
fair packet scheduler except that a per-traffic stream multiplier
is applied to each stream.
The class definition is as follows:
NAME WeightedRoundRobinPacket
SchedulingService
DESCRIPTION A concrete class used to represent a
Weighted packet scheduling service.
DERIVED FROM RoundRobinPacketSchedulingService
TYPE Structural
PROPERTIES WeightingFactor, Priority
4.3.23.1. The Property WeightingFactor
This real 32-bit attribute is used to define the weighting factor
that will be used to offer some queues a higher probability of
being serviced than other queues. This attribute represents this
probability.
4.3.23.2. The Property Priority
This 16-bit unsigned integer specifies a tie breaker in the event
that two or more queues achieve an equal weighting. While this
condition may not occur in some implementations of a weighted
round robin scheduler, there are many implementations that
require a priority to resolve it. However, in instances where
this behavior is not necessary or undesirable, this attribute may
be left unspecified.
4.3.24. The Class QoSService
This is a new concrete class that is defined in this model. It
represents the ability to conceptualize a QoS service as a set of
coordinated sub-services. This enables the network administrator
to map business rules to the network, and the network designer to
engineer the network such that it can provide different functions
for different traffic streams.
Strassner, et al. Expires: Jul 2000 + 6 months [Page 42]
Internet Draft QoS Device Info Model July 2000
This class has two main purposes. First, it serves as a common
base class for defining various sub-services that are needed to
build higher-level QoS services. Second, it serves as a way to
consolidate relationships between different types of QoS services
and different types of ConditioningServices.
For example, Gold Service may be defined as a set of sub-
services, where each of these sub-services perform one or more
different functions required by the higher-level service.
Continuing the example, Gold Service may be used to specify EF
for one traffic stream along with different AF services for other
different traffic streams. Each of these services are instances
of the class QoSService, and each require a set of sub-services
to be defined as part of their implementation. For example, one
would expect to see different marking, dropping, and queuing sub-
services to be defined for each of these services.
This is modeled as a type of NetworkService, which is used as the
anchor point for defining a set of sub-services that implement
the desired conditioning characteristics for different types of
flows. It will direct the specific type of ConditioningServices
to be used in order to implement this service.
The class definition is as follows:
NAME QoSService
DESCRIPTION A concrete class used to represent a QoS
service or set of services, as defined
by a network administrator.
DERIVED FROM NetworkService
TYPE Structural
PROPERTIES None
4.3.25. The Class DiffServService
This is a new concrete class, defined in this model. This class
represents using standard or custom DiffServ services to
implement a (higher-level) QoS service. Note that the
DiffServService may be just one of a set of coordinated
QoSSubServices that together implement a higher-level QoS
service.
DiffServService is modeled as a specialization of QoSService.
This enables it to be related to a higher-level QoS service (via
QoSSubService) as well as to specific ConditioningServices (e.g.,
classification, metering, dropping, queuing, and others).
The class definition is as follows:
NAME DiffServService
DESCRIPTION A concrete class used to represent a
DiffServ service, or a set of DiffServ
Strassner, et al. Expires: Jul 2000 + 6 months [Page 43]
Internet Draft QoS Device Info Model July 2000
services.
DERIVED FROM QoSService
TYPE Structural
PROPERTIES DSCP
4.3.25.1. The Property DSCP
This attribute is an unsigned 8-bit integer. It defines the
Differentiated Services Code Point used to represent various
types of differentiated services, through device-specific
configuration commands.
4.3.26. The Class AFService
This is a new concrete class that is defined in this model. It
represents a specialization of the general concept of forwarding
network traffic by adding specific semantics that characterize
the operation of the Assured Forwarding (AF) Service ([R2597]).
[R2597] defines four different AF classes to represent four
different treatments of traffic (e.g., a different amount of
forwarding resources, such as buffer space and bandwidth, are
allocated. Within each AF class, IP packets are marked with one
of three possible drop precedence values. The drop precedence of
a packet determines the relative importance of that packet
compared to other packets within the same AF class, if congestion
occurs. A congested interface will try to avoid dropping packets
with a lower drop precedence value by instead discarding packets
with a higher drop precedence value.
Note that [R2597] defines 12 DSCPs that together implement the AF
Per-Hop Behavior (PHB) group. Implementations are free to extend
this (e.g., add more classes and/or drop precedences).
The AFService class is modeled as a specialization of
DiffServService, which is in turn a specialization of QoSService.
This enables it to be related to a higher-level QoS services as
well as to lower-level sub-services (e.g., classification,
metering, dropping, queuing, and others).
The class definition is as follows:
NAME AFService
DESCRIPTION A concrete class for describing the
common characteristics of differentiated
services that are used to affect
traffic forwarding, using the AF
PHB Group.
DERIVED FROM DiffServService
TYPE Structural
PROPERTIES ClassNumber, DropperNumber
Strassner, et al. Expires: Jul 2000 + 6 months [Page 44]
Internet Draft QoS Device Info Model July 2000
4.3.26.1. The Property ClassNumber
This attribute is an 8-bit unsigned integer that defines the
number of classes that this AF implementation uses.
Implementations should define at least 4 classes.
4.3.26.2. The Property DropperNumber
This attribute is an 8-bit unsigned integer that defines the
number of drop precedences that this AF implementation uses. The
number of drop precedence values are PER AF CLASS.
Implementations should define at least three drop precedence
values per class.
4.3.27. The Class EFService
This is a new concrete class, defined in this model. It
represents a specialization of the general concept of forwarding
network traffic by adding specific semantics that characterize
the operation of the Expedited Forwarding (EF) Service ([R2598]).
The EFService class is modeled as a specialization of
DiffServService, which is in turn a specialization of QoSService.
This enables it to be related to a higher-level QoS service as
well as to lower-level sub-services (e.g., classification,
metering, dropping, queuing, and others).
The EF PHB can be used to build a low loss, low latency, low
jitter, assured bandwidth, end-to-end service through DiffServ
domains. Such a service appears to the endpoints like a point-
to-point connection or a virtual leased line. This service has
also been described as Premium service.
[R2598] defines one DSCP for the EF service. The inherited DSCP
property will contain this value for all instances.
The class definition is as follows:
NAME EFService
DESCRIPTION A concrete class for describing the
common characteristics of differentiated
services that are used to affect
traffic forwarding using the EF
PHB Group.
DERIVED FROM DiffServService
TYPE Structural
PROPERTIES None
4.3.28. The Class PrecedenceService
This is a new concrete class that is defined in this model. It
represents a specialization of the general concept of forwarding
Strassner, et al. Expires: Jul 2000 + 6 months [Page 45]
Internet Draft QoS Device Info Model July 2000
network traffic by adding specific semantics that define how
traffic is forwarded based on the value of the ToS byte of a
packet.
This class is used to enable DiffServ devices and non-DiffServ
devices to exchange traffic. This is done by defining a sibling
class, DiffServService, to represent devices that forward traffic
based on the DiffServ code point. This enables the administrator
to define mappings between devices that do not support DiffServ,
and instead use IP Precedence, to devices that do support
DiffServ, which use DSCPs.
Since the PrecedenceService class is a specialization of
QoSService, it can be related to higher-level QoS services using
the QoSSubService association. Also, it can be related to lower-
level sub-services (e.g., classification, metering, dropping,
queuing, and others), using the QoSConditioingSubService
association.
The class definition is as follows:
NAME PrecedenceService
DESCRIPTION A concrete class for describing the
common characteristics of forwarding
traffic based on the value of the
ToS byte.
DERIVED FROM DiffServService
TYPE Structural
PROPERTIES PrecedenceValue
4.3.28.1. The Property PrecedenceValue
This attribute is an 8-bit unsigned integer that defines the
notion of precedence for different types of traffic. See [R2474]
for more information on the definition, backward compatibility
with the ToS byte of IPv4 traffic, and use of this attribute.
4.3.29. The Class 8021PService
This is a new concrete class that is defined in this model. It
represents a specialization of the general concept of forwarding
network traffic by adding specific semantics that define how
traffic is forwarded based on the value of the Priority field in
the 802.1P header.
This class is used to enable DiffServ devices and domains that
support 802.1P, to exchange traffic. It allows implementations
that only support 802.1P priority marking to be mapped to
implementations that support DiffServ, which uses DSCPs.
Strassner, et al. Expires: Jul 2000 + 6 months [Page 46]
Internet Draft QoS Device Info Model July 2000
Since the 8021PService class is a specialization of QoSService,
it can be related to higher-level QoS services using the
QoSSubService association. Also, it can be related to lower-level
sub-services (e.g., classification, metering, dropping, queuing,
and others), using the QoSConditioingSubService association.
The class definition is as follows:
NAME 8021PService
DESCRIPTION A concrete class for describing the
common characteristics of forwarding
traffic based on the value of the
Priority field in the 802.1P header.
DERIVED FROM QoSService
TYPE Structural
PROPERTIES PriorityValue
4.3.29.1. The Property PriorityValue
This attribute is an 8-bit unsigned integer that defines the
notion of priority as specified in 802.1P implementations.
4.3.30. The Class FilterEntryBase
A simplistic but accurate view of the CIM filter classes is of:
- FilterEntries aggregated into FilterLists,
- Which are then used by the ClassifierService
- To separate incoming traffic into different traffic classes
(and service levels).
FilterEntryBase is an abstract class that is defined in the
Network Model of CIM. It is a base class for all filter entries,
and is the endpoint of the association aggregating filter entries
into filter lists. Its properties include CIM naming attributes
and an IsNegated Boolean property (to easily "NOT" the match
information specified in FilterEntryBase's subclasses). Please
refer to [CIM] for the full definition of this class.
4.3.31. The Class FilterEntry
FilterEntry is a concrete class defined in the Network Model of
CIM. It is specific to packet filtering, identifying traffic for
forwarding/further processing or for dropping. Please refer to
[CIM] for the full definition of this class.
FilterEntry's properties include:
Strassner, et al. Expires: Jul 2000 + 6 months [Page 47]
Internet Draft QoS Device Info Model July 2000
- TrafficType (an enumeration) - Indicates the type of traffic
that is filtered. This property affects what can be
specified in MatchCondition. Currently, only IP-related
values are defined ("IPv4", "IPX" and "IPv6").
- MatchConditionType (an enumeration) - Specifies the type of
condition that will be matched - source/destination address
and mask, port or port range, protocol type, DiffServ
codepoint, ToS Value, 802.1 Priority, etc.
- OtherMatchConditionType (a string) - When the
MatchConditionType is "Other" (value = 1), this string
explicitly describes the type of MatchCondition.
- MatchConditionValue (a string) - Indicates the specific
value(s) to match (or NOT match if the inherited IsNegated
property is TRUE).
- ActionType (an enumeration) - Specifies "Permit" or
"Deny" actions for the traffic class.
- DefaultFilter (a Boolean) - Defines this FilterEntry as the
"default" one when aggregated in a FilterList.
- TrafficClass (a string) - Specifies the label for the
traffic class of a packet, when that packet is matched by
the FilterEntry. Traffic class information is carried
through the sequence of ConditioningServices via the
NextService.TrafficClass property.
4.3.32. The Class FilterList
A concrete class defined in the Network Model of CIM. It
aggregates instances (of subclasses) of FilterEntryBase via the
association, EntriesInFilterList. It is possible to aggregate
different types of Filters into a single List - for example,
aggregating packet filters (which are instances of FilterEntry)
and security filters (which are being defined for the next
release of the CIM Network Model).
The association property, EntriesInFilterList.EntrySequence,
serves to order the filter entries in the FilterList. This is
very useful when algorithms such as "Match First" are used to
identify traffic based on the aggregated Filters. If
EntrySequence is set to 0, then all aggregated Filters should be
ANDed together to define a class of traffic.
Please refer to [CIM] for the full definition of the FilterList
and EntriesInFilterList classes.
Strassner, et al. Expires: Jul 2000 + 6 months [Page 48]
Internet Draft QoS Device Info Model July 2000
4.3.33. The Class ServiceAccessPoint
This is an abstract class that is defined in the Core Model of
CIM. It is a subclass of the LogicalElement class, and is the
base class for all objects which manage access to CIM_Services.
It represents the management of utilizing or invoking a Service.
Please refer to [CIM] for the full definition of this class.
4.3.34. The Class ProtocolEndpoint
This is a concrete class that is defined in the Network Common
Model of CIM. It subclasses from ServiceAccessPoint and
describes a communication point from which the Services of the
network, or the System's protocol stack may be accessed. Please
refer to [CIM] for the full definition of this class.
4.3.35. The Class Collection
This is an abstract class that is defined in the Core Model of
CIM. It is a superclass for all objects that are groupings or
bags, and carry no status or "state" (the latter would be more
correctly modeled as ManagedSystemElements). Please refer to
[CIM] for the full definition of this class.
4.3.36. The Class CollectionOfMSEs
This is an abstract class that is defined in the Core Model of
CIM. It is a specialization of the Collection superclass,
restricting the contents of the Collection to
ManagedSystemElements. Please refer to [CIM] for the full
definition of this class.
4.3.37. The Class BufferPool
This is a new concrete class, defined in this model. It
represents the collection of buffers used by a QueuingService.
(The association QueueAllocation describes this usage semantic.)
The existence and management of individual buffers will be
modeled in a future release. At the current level of abstraction,
modeling the existence of the BufferPool is necessary. Long
term, it is not sufficient.
In implementations where there are multiple buffer sizes, an
instance of BufferPool should be defined for each set of buffers
with identical or similar sizes. These instances of buffer pools
can then be grouped together using the CollectedBuffersPool
association.
Note that this class is derived from CollectionOfMSEs, and not
from Forwarding or ConditioningService. BufferPool is only a
collection of storage, and is NOT a Service.
Strassner, et al. Expires: Jul 2000 + 6 months [Page 49]
Internet Draft QoS Device Info Model July 2000
The class definition is as follows:
NAME BufferPool
DESCRIPTION A concrete class describing the
a collection of buffers.
DERIVED FROM CollectionOfMSEs
TYPE Structural
PROPERTIES CollectionID, CreationClassName,
Name, BufferSize, TotalBuffers,
AvailableBuffers, SharedBuffers
4.3.37.1. The Property CollectionID
CollectionID is a string property of maximum length 256
characters. It identifies the buffer pool.
4.3.37.2. The Property CreationClassName
This attribute is a string property of maximum length 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.
4.3.37.3. The Property Name
This attribute is a string of maximum length 256 characters. It
is the common name or label by which the object is known.
4.3.37.4. The Property BufferSize
This attribute is a 16-bit unsigned integer, defining the number
of bytes in each buffer in the buffer pool.
4.3.37.5. The Property TotalBuffers
This attribute is a 32-bit unsigned integer, defining the total
number of individual buffers in the pool.
4.3.37.6. The Property AvailableBuffers
This attribute is a 32-bit unsigned integer, defining the number
of buffers in the Pool that are currently not allocated to any
instance of a QueuingService. Buffers allocated to a
QueuingService could either be in use (containing packet data),
or allocated to a Queue pending the arrival of new packet data.
4.3.37.7. The Property SharedBuffers
This attribute is a 32-bit unsigned integer, and defines the
number of buffers in the Pool that have been simultaneously
allocated to multiple instances of QueuingService.
Strassner, et al. Expires: Jul 2000 + 6 months [Page 50]
Internet Draft QoS Device Info Model July 2000
4.4. Relationships Defined in the State Portion of the Model
This section details the QoS device class associations, that were
presented earlier and drawn in Figure 5. These relationships are
defined as classes (that can have properties) in the Information
Model.
4.4.1. The Association Dependency
This abstract association defines two object references (named
Antecedent and Dependent) that are used to 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 CIM Core Model. 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 CIM Core Model. Please refer
to [CIM] for the full definition of this class.
4.4.3. The Association ConditioningServiceOnEndpoint
This association is new, defined in this model. It establishes a
dependency relationship between a ProtocolEndpoint object and a
ConditioningService object. This relationship indicates that the
referenced ProtocolEndpoint is used by the ConditioningService
for traffic to enter or leave the device. The latter is
distinguished by the property ServiceType, which indicates
whether the ConditioningService object handles incoming or out-
going traffic. The ProtocolEndpoint represents whether the
traffic arrives at or leave from a network device, and the
ConditioningService which begins or ends the traffic conditioning
process within a network device.
This class is subclassed from the ServiceSapDependency
association. It restricts the Antecedent to instances of the
ProtocolEndpoint class (instead of the more generic
Strassner, et al. Expires: Jul 2000 + 6 months [Page 51]
Internet Draft QoS Device Info Model July 2000
ServiceAccessPoint class) and further restricts the cardinality
of this end of the relationship to be 0-or-1 (instead of the more
generic 0-or-more). It restricts the Dependent to instances of
the ConditioningService class (instead of the more generic
Service class) and further restricts the cardinality of this end
of the relationship to be 0-or-1 (instead of the more generic 0-
or-more).
The class definition for this association is as follows:
NAME ConditioningServiceOnEndpoint
DESCRIPTION A generic association used to establish
dependency relationships between a
ConditioningService object and a
ProtocolEndpoint object.
DERIVED FROM ServiceSAPDependency
ABSTRACT False
PROPERTIES Antecedent[ref ProtocolEndpoint[0..1]],
Dependent[ref ConditioningService[0..1]],
ServiceType
4.4.3.1. The Reference Antecedent
This property is inherited from the ServiceSAPDependency
association, and overridden for two reasons - To serve as an
object reference to a ProtocolEndpoint object (instead of the
more general ServiceAccessPoint object), and To update
cardinality. This reference defines the ProtocolEndpoint through
which traffic arrives at or leaves from a network device.
4.4.3.2. The Reference Dependent
This property is inherited from the ServiceSAPDependency
association, and overridden to serve as an object reference to a
ConditioningService object (instead of the more general Service
object) and to update cardinality. This reference indicates the
ConditioningService that begins or ends the traffic conditioning
processing within a network device.
4.4.3.3. The Property ServiceType
This property is a 16-bit unsigned integer that indicates whether
a packet is incoming (value = 1, "Ingress") or out-going (value =
2, "Egress") at the ProtocolEndpoint, relative to the
ConditioningService.
4.4.4. The Association ServiceServiceDependency
This association defines two object references that establish a
dependency relationship between two Service objects. The
particular type of dependency is described by the
TypeOfDependency property; typical examples include that one
Strassner, et al. Expires: Jul 2000 + 6 months [Page 52]
Internet Draft QoS Device Info Model July 2000
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 CIM Core Model. Please refer
to [CIM] for the full definition of this class.
4.4.5. The Association QueueHierarchy
This association is new, defined in this model. It is a subclass
of ServiceServiceDependency, and defines two object references
that are used to establish a dependency relationship between two
QueuingService objects.
The class definition is as follows:
NAME QueueHierarchy
DESCRIPTION A generic association used to establish
dependency relationships between two
QueuingService objects.
DERIVED FROM ServiceServiceDependency
ABSTRACT False
PROPERTIES Antecedent[ref QueuingService[0..1]],
Dependent[ref QueuingService[0..n]]
4.4.5.1. The Reference Antecedent
This property is inherited from the ServiceServiceDependency
association, and overridden to serve as an object reference to a
QueuingService object (instead of the more general Service
object). It also restricts the cardinality of this end of the
relationship to 0-or-1 (instead of the more generic 0-or-more).
This reference defines the supporting queue through its
QueuingService. This QueuingService can only support at most one
higher-level QueuingService.
4.4.5.2. The Reference Dependent
This property is inherited from the ServiceServiceDependency
association, and overridden to serve as an object reference to a
QueuingService object (instead of the more general Service
object). This reference indicates the QueuingService that depends
on another QueuingService.
Strassner, et al. Expires: Jul 2000 + 6 months [Page 53]
Internet Draft QoS Device Info Model July 2000
4.4.6. The Association SchedulerUsed
This association is new, defined in this model. It is a subclass
of ServiceServiceDependency, and defines two object references
that establish a dependency relationship between a
PacketSchedulingService and one or more QueuingService objects.
The class definition is as follows:
NAME SchedulerUsed
DESCRIPTION A generic association used to establish
dependency relationships between a
specific PacketSchedulingService and one
or more QueuingService objects.
DERIVED FROM ServiceServiceDependency
ABSTRACT False
PROPERTIES Antecedent[ref
PacketSchedulingServiceService[0..1]],
Dependent[ref QueuingService[0..n]]
4.4.6.1. The Reference Antecedent
This property is inherited from the ServiceServiceDependency
association, and overridden to serve as an object reference to a
PacketSchedulingService object (instead of the more general
Service object). It also restricts the cardinality of this
relationship to exactly 1 instance (instead of the more generic
0-or-more instances). This reference defines the
PacketSchedulingService, which is used to empty the queue(s)
controlled by the QueuingService.
4.4.6.2. The Reference Dependent
This property is inherited from the ServiceServiceDependency
association, and overridden to serve as an object reference to a
QueuingService object (instead of the more general Service
object). This reference indicates the queue(s) and the associated
QueuingService that depends on the PacketSchedulingService.
4.4.7. The Association AFRelatedServices
This association is new, defined in this model. It 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
Strassner, et al. Expires: Jul 2000 + 6 months [Page 54]
Internet Draft QoS Device Info Model July 2000
AFService objects.
DERIVED FROM Nothing
ABSTRACT False
PROPERTIES AFLowerDropPrecedence[ref
AFService[0..1]],
AFHigherDropPrecedence[ref
AFService[0..n]]
4.4.7.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.7.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.8. The Association NextService
This association is new, defined in this model. It defines two
object references that establish a dependency 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 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 dependency relationship between two
ConditioningService objects.
DERIVED FROM Nothing
ABSTRACT False
PROPERTIES PrecedingService[ref
ConditioningService[0..n]],
FollowingService[ref
ConditioningService[0..n]],
TrafficClass
Strassner, et al. Expires: Jul 2000 + 6 months [Page 55]
Internet Draft QoS Device Info Model July 2000
4.4.8.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.8.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.
4.4.8.3. The Property TrafficClass
This property is a string that is used to identify different
traffic flows that have been separated by the Classifier
ConditioningService.
This property enables a ConditioningService to forward multiple
traffic flows to (for example) the same "next"
ConditioningService while maintaining their traffic identity.
4.4.9. The Association NextServiceAfterMeter
This association is new, defined in this model. It defines two
object references that establish a dependency relationship
between a MeterService and one or more ConditioningService
objects that process traffic from the MeterService. It subclasses
the NextService association to restrict the independent (or
PrecedingService) to be a MeterService.
Meters are 1:n fan-out elements, which means that we need a way
to distinguish between the different outputs of the meter.
Therefore, this association also defines a new property,
MeterResult, which can be used to identify which output of the
meter this traffic originated from.
The class definition is as follows:
NAME NextServiceAfterMeter
DESCRIPTION An association used to establish
a dependency relationship between a
particular output of a MeterService
and the next ConditioningService
object that is responsible for further
processing of the traffic.
DERIVED FROM NextService
ABSTRACT False
PROPERTIES PrecedingService[ref MeterService[0..n]],
MeterResult
Strassner, et al. Expires: Jul 2000 + 6 months [Page 56]
Internet Draft QoS Device Info Model July 2000
4.4.9.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 MeterService, as opposed to the more general
ConditioningService defined in the NextService superclass.
This property serves as an object reference to a MeterService
object that occurs earlier in the processing sequence for a given
type of traffic. 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.9.2. 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 in- or out-of-profile, or
partially conforming. More complicated metering can be built by
either extending the enumeration or by cascading meters.
The enumerated values are: "Unknown" (0), "In-profile" (1),
"Partially Conforming" (2), "Out-of-profile" (3).
4.4.10. The 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 CIM Core Model. Please refer
to [CIM] for the full definition of this class.
4.4.11. 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 subclassed from the more generic Component
superclass to restrict the types of objects that can participate
in this relationship.
The association is defined in the CIM Core Model. Please refer
to [CIM] for the full definition of this class.
4.4.12. The Aggregation QoSSubService
This association is new, defined in this model. It is used to
model a set of subordinate QoSServices that are aggregated
together to form a higher-level QoSService. A QoSService is a
Strassner, et al. Expires: Jul 2000 + 6 months [Page 57]
Internet Draft QoS Device Info Model July 2000
specific type of Service that conceptualizes QoS functionality as
a set of coordinated sub-services.
This aggregation is subclassed 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.12.1. The Reference GroupComponent
This property is overridden in this relationship to represent an
object reference to a QoSService object (instead of the more
generic Service object defined in its superclass). This object
represents the parent, or aggregate, object in the relationship.
4.4.12.2. The Reference PartComponent
This property is overridden in this relationship to represent an
object reference to a QoSService object (instead of the more
generic Service object defined in its superclass). This object
represents the child, or "component", object in the relationship.
4.4.13. The Aggregation QoSConditioningSubService
This association is new, defined in this model. It is used to
define the set of ConditioningServices that together condition
traffic for a particular QoSService.
This aggregation is subclassed from the more generic
ServiceComponent superclass to restrict the types of objects that
can participate in this relationship to ConditioningService and
QoSService objects, instead of a more generic Service object.
The class definition for the aggregation is as follows:
Strassner, et al. Expires: Jul 2000 + 6 months [Page 58]
Internet Draft QoS Device Info Model July 2000
NAME QoSConditioningSubService
DESCRIPTION A generic association used to establish
"part-of" relationships between a set
of ConditioningService objects and the
particular QoSService object that they
provide traffic conditioning for.
DERIVED FROM ServiceComponent
ABSTRACT False
PROPERTIES GroupComponent[ref QoSService[0..1]],
PartComponent[ref
ConditioningService[0..n]]
4.4.13.1. The Reference GroupComponent
This property is overridden in this relationship to represent an
object reference to a QoSService object (instead of the more
generic Service object defined in its superclass). It also
restricts the cardinality of the aggregate to 0-or-1 (instead of
the more generic 0-or-more).
This object represents the parent, or aggregate, object in the
relationship. 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.13.2. The Reference PartComponent
This property is overridden in this relationship to represent an
object reference to a ConditioningService object (instead of 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 define how traffic for
a specific QoSService will be conditioned.
4.4.14. 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 association's cardinality is many to many.
The association is defined in the CIM Core Model. Please refer
to [CIM] for the full definition of this class.
4.4.15. The Aggregation CollectedBufferPool
This relationship is used to model 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.
Strassner, et al. Expires: Jul 2000 + 6 months [Page 59]
Internet Draft QoS Device Info Model July 2000
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..n]],
Member[ref BufferPool[0..n]]
4.4.15.1. The Reference Collection
This property represents the parent, or aggregate, object in the
relationship. It is a BufferPool object.
4.4.15.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.16. The Aggregation EntriesInFilterList
This aggregation is a specialization of the Component association
and is used to define a set of filter entries (subclasses of
FilterEntryBase) that are aggregated by a FilterList. Cardinality
is many to many.
The association is defined in the Network Model of CIM. Please
refer to [CIM] for the full class definition.
5. Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; neither does it represent
that it has made any effort to identify any such rights.
Information on the IETF's procedures with respect to rights in
standards-track and standards-related documentation can be found
in BCP-11.
Copies of claims of rights made available for publication and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the
use of such proprietary rights by implementers or users of this
specification can be obtained from the IETF Secretariat.
Strassner, et al. Expires: Jul 2000 + 6 months [Page 60]
Internet Draft QoS Device Info Model July 2000
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 working group for their many helpful comments and
suggestions.
7. Security Considerations
Security and denial of service considerations are not explicitly
considered in this memo, as they are appropriate for the
underlying policy architecture implementing the distribution and
communication of the information described in this draft.
Specifically, any mechanisms used to distribute and communicate
the information described in this draft must minimize theft and
denial of service threats. Second, it must be ensured that the
entities involved in policy control can verify each other's
identity and establish necessary trust before communicating.
The communication tunnel between policy clients and policy
servers SHOULD be secured by the use of an IPSEC [R1825] channel.
It is advisable that this tunnel makes use of both the AH
(Authentication Header) and ESP (Encapsulating Security Payload)
protocols, in order to provide confidentiality, data origin
authentication, integrity and replay prevention.
8. References
[CIM] Common Information Model (CIM) Schema, version 2.x.
Distributed Management Task Force, Inc. The
components of the CIM schema are available via links on
the following DMTF web page:
http://www.dmtf.org/spec/cims.html.
[DSMIB] Management Information Base for the Differentiated
Services Architecture. Internet Draft, draft-ietf-diffserv-
mib-03.txt, F. Baker, K. Chan, and A. Smith. May 2000.
[DSMODEL] A Conceptual Model for DiffServ Routers. Internet
Draft, draft-ietf-diffserv-model-03.txt, Y. Bernet, A. Smith,
S. Blake, and D. Grossman. May 2000.
Strassner, et al. Expires: Jul 2000 + 6 months [Page 61]
Internet Draft QoS Device Info Model July 2000
[PCIM] Policy Core Information Model - Version 1 Specification.
Internet Draft, draft-ietf-policy-core-info-model-07.txt, B.
Moore, E. Ellison, J. Strassner, and A. Westerinen. July
2000.
[PIB] Quality of Service Policy Information Base. Internet
Draft, draft-mfine-cops-pib-02.txt, M. Fine, K. McCloughrie,
J. Seligson, K. Chan, S. Hahn, and A. Smith. October 1999.
[POLTERM] Policy Terminology. Internet Draft, draft-ietf-policy-
terminology-00.txt, A. Westerinen, J. Schnizlein, J.
Strassner, M. Scherling, B. Quinn, J. Perry, S. Herzog, A.
Huynh, and M. Carlson. July 2000.
[QOSPIM] Policy Framework QoS Information Model. Internet Draft,
draft-ietf-policy-qos-info-model-01.txt, Y. Snir, Y. Ramberg,
J. Strassner, and R. Cohen. April 2000.
[QOSSCH] QoS Policy Schema. Internet Draft, draft-itef-policy-
qos-schema-01.txt, Y. Snir, Y. Ramberg, J. Strassner, and R.
Cohen. February 2000.
[R1633] Integrated Services in the Internet Architecture: An
Overview. R. Braden, D. Clark, and S. Shenker. June 1994.
[R1825] Security Architecture for the Internet Protocol. R.
Atkinson. August 1995.
[R2119] Key words for use in RFCs to Indicate Requirement Levels.
S. Bradner. March 1997.
[R2474] Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers. K. Nichols, S. Blake, F.
Baker, and D. Black. December 1998.
[R2475] An Architecture for Differentiated Service. S. Blake, D.
Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss. December
1998.
[R2597] Assured Forwarding PHB Group. J. Heinanen, F. Baker, W.
Weiss, and J. Wroclawski. June 1999.
[R2598] An Expedited Forwarding PHB. V. Jacobson, K. Nichols,
and K. Poduri. June 1999.
[RED] See http://www-nrg.ee.lbl.gov/floyd/red.html.
[UMLUG] The Unified Modeling Language User Guide. G. Booch, J.
Rumbaugh, and I. Jacobson. Addison-Wesley, 1999.
Strassner, et al. Expires: Jul 2000 + 6 months [Page 62]
Internet Draft QoS Device Info Model July 2000
9. Authors' Addresses
John Strassner
Cisco Systems, Bldg 15
170 West Tasman Drive
San Jose, CA 95134
E-mail: johns@cisco.com
Andrea Westerinen
Cisco Systems, Bldg 15
170 West Tasman Drive
San Jose, CA 95134
E-mail: andreaw@cisco.com
Bob Moore
IBM Corporation, BRQA/502
4205 S. Miami Blvd.
Research Triangle Park, NC 27709
E-mail: remoore@us.ibm.com
10. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to
the Internet Society or other Internet organizations, except as
needed for the purpose of developing Internet standards in which
case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate
it into languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
Strassner, et al. Expires: Jul 2000 + 6 months [Page 63]
