One document matched: draft-ietf-policy-qos-device-info-model-00.txt
Policy Framework Working Group J. Strassner (Cisco)
INTERNET-DRAFT W. Weiss (Lucent)
March 2000 D. Durham (Intel)
A. Westerinen (SNIA)
Information Model for Describing Network Device QoS Mechanisms
<draft-ietf-policy-qos-device-info-model-00.txt>
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.
Abstract
The purpose of this draft is to define an information model that
describes the QoS capabilities of different devices. These capabilities
define the attributes common to the classification, conditioning,
queuing, and forwarding characteristics of network devices running
Differentiated Services QoS as well as (in the future) RSVP. 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 capabilities) 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 second draft [QCAPSCH] 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 draft is similarly paired with the draft specified in [QOSSCH],
which describes a mapping of the data in [QOSPIM] to a form suitable
for implementation in a directory that uses (L)DAP as its access
protocol. These two drafts then describe how to write QoS policy rules
that can be used to store information in directories that can be used
to configure device QoS mechanisms.
Strassner, et. al. Expires September 2000 [Page 1
INTERNET-DRAFT QoS Device Info Model March, 2000
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, reference [5].
Table of Contents
Status of this memo 1
Copyright Notice 1
Abstract 1
Definition of Key Word Usage 2
Table of Contents 2
1. Introduction 5
1.1 Policy Management Conceptual Model 6
1.2 Typical Examples of Policy Usage 7
2. Approach 8
2.1. Common Needs Of DiffServ and IntServ 8
2.2. Specific Needs Of DiffServ 9
2.3. Specific Needs Of IntServ 9
3. Methodology 10
3.1 Level of Abstraction for Expressing QoS Policies 10
3.2 Level of Abstraction for Defining QoS Attributes and Classes 12
3.3 Characterization of QoS Attributes 12
3.4 Identifying Common Shared Policies 13
3.5 QoS Information Model Derivation 13
3.6 Attribute Representation 14
3.7 Mental Model 15
4. The Class Hierarchy 16
4.1 Difference Between Inheritance and Relationship Hierarchies 16
4.1.1 Associations 16
4.1.2. Aggregations 17
4.2. The Structure of the Class Hierarchy 17
4.2.1 The Class Hierarchy for Modeling State Information 17
4.2.2 The Class Hierarchy for Modeling Configuration Information 20
4.3 Class Definitions for the State Portion of the Model 21
4.3.1 The Class ManagedSystemElement 21
4.3.2 The Class LogicalElement 21
4.3.3 The Class Service 21
4.3.4 The Class NetworkService 21
4.3.5 The Class ForwardingService 22
4.3.6 The Class TrafficConditioningBlock 22
4.3.6.1 The Attribute Enabled 22
4.3.6.2 The Attribute ID 23
Strassner, et. al. Expires September 2000 [Page 2
INTERNET-DRAFT QoS Device Info Model March, 2000
4.3.7 ClassifierService 23
4.3.7.1 The Attribute ClassifierType 23
4.3.7.2 The Attribute OtherClassifierType 24
4.3.7.3 The Attribute IsIngress 24
4.3.7.4 The Attribute Status 24
4.3.7.5 The Attribute TrafficClasses 24
4.3.8 MeterService 24
4.3.8.1 The Attribute MeterType 25
4.3.8.2 The Attribute ConformanceLevels 25
4.3.8.3 The Attribute OtherMeterConformance 25
4.3.8.4 The Attribute FailAction 26
4.3.8.5 The Attribute SucceedAction 26
4.3.9 The Class AverageRateMeter 26
4.3.9.1 The Attribute Rate 26
4.3.9.2 The Attribute Interval 26
4.3.10 The Class EWMAMeter 27
4.3.10.1 The Attribute AverageRate 27
4.3.10.2 The Attribute Delta 27
4.3.10.3 The Attribute Interval 27
4.3.10.4 The Attribute Gain 28
4.3.11 The Class TokenBucketMeter 28
4.3.11.1 The Attribute AverageRate 28
4.3.11.2 The Attribute PeakRate 29
4.3.11.3 The Attribute BurstSize 29
4.3.11.4 The Attribute ExcessBurstSize 29
4.3.12 The Class MarkerService 29
4.3.12.1 The Attribute CanRemark 29
4.3.12.2 The Attribute RemarkType 30
4.3.12.3 The Attribute RemarkValue 30
4.3.13 The Class DropperService 30
4.3.13.1 The Attribute DropperType 30
4.3.13.2 The Attribute OtherDropperType 31
4.3.13.3 The Attribute AlwaysDrop 31
4.3.13.4 MinQueueThreshold 31
4.3.13.5 MaxQueueThreshold 31
4.3.14 The Class HeadTailDropper 31
4.3.14.1 The Attribute IsTailDropper 32
4.3.15 The Class REDDropper 32
4.3.15.1 The Attribute StartProbability 32
4.3.15.2 The Attribute StopProbability 32
4.3.15.3 The Attribute StartPercent 32
4.3.15.4 The Attribute StopPercent 33
4.3.16 The Class WeightedREDDropper 33
4.3.16.1 The Attribute DropMetric 33
4.3.16.2 The Attribute OtherDropMetric 33
4.3.16.3 The Attribute Weight 34
4.3.17 The Class QueuingService 34
4.3.17.1 The Attribute SmoothingWeight 34
4.3.17.2 The Attribute Interval 34
Strassner, et. al. Expires September 2000 [Page 3
INTERNET-DRAFT QoS Device Info Model March, 2000
4.3.18 The Class BufferManagementService 35
4.3.18.1 The Attribute BufferSize 35
4.3.18.2 The Attribute TotalBuffers 35
4.3.18.3 The Attribute AvailableBuffers 35
4.3.18.4 The Attribute SharedBuffers 35
4.3.19 The Class PacketSchedulingService 36
4.3.19.1 The Attribute SchedulerType 36
4.3.19.2 The Attribute OtherSchedulerType 36
4.3.19.3 The Attribute GiveExcessCapacity 37
4.3.20 The Class PriorityScheduler 37
4.3.21 The Class PriorityBandwidthScheduler 37
4.3.21.1 The Attribute BandwidthAllocation 38
4.3.21.2 The Attribute BurstsAllowed 38
4.3.21.3 The Attribute BurstAllocation 38
4.3.22 The Class BandwidthScheduler 38
4.3.22.1 The Attribute BandwidthAllocation 38
4.3.22.2 The Attribute BurstsAllowed 39
4.3.22.3 The Attribute BurstAllocation 39
4.3.22.4 The Attribute CanShare 39
4.3.22.5 The Attribute WorkConserving 39
4.3.23 The Class RoundRobinPacketScheduler 39
4.3.24 The Class WeightedRoundRobinPacketScheduler 40
4.3.24.1 The Attribute WeightingFactor 40
4.3.24.2 The Attribute Priority 40
4.3.25 The Class QoSService 40
4.3.25.1 The Attribute AllowClassificationService 41
4.3.25.2 The Attribute AllowMarkingService 41
4.3.25.3 The Attribute AllowDroppingService 41
4.3.25.4 The Attribute AllowMeteringService 41
4.3.25.5 The Attribute AllowQueuingService 42
4.3.25.6 The Attribute AllowSchedulingService 42
4.3.25.7 The Attribute AllowSignalingService 42
4.3.26 The Class DiffService 42
4.3.26.1 The Attribute DSCP 42
4.3.27 The Class AFService 43
4.3.27.1 The Attribute ClassNumber 43
4.3.27.2 The Attribute DropperNumber 43
4.3.28 The Class EFService 43
4.3.29 The Class PrecedenceService 44
4.3.29.1 The Attribute PrecedenceValue 44
4.3.30 The Class 8021PService 45
4.3.30.1 The Attribute PriorityValue 45
4.4 Relationships Defined in the State Portion of the Model 45
4.5 Classes Defined in the Configuration Portion of the Model 46
4.6 Relationships Defined in the Configuration Portion of the Model 46
5. Mapping to Example Policies 47
6. Security Considerations 48
7. Acknowledgments 48
8. References 48
9. Author's Addresses 50
10. Full Copyright Statement 50
Strassner, et. al. Expires September 2000 [Page 4
INTERNET-DRAFT QoS Device Info Model March, 2000
1. Introduction
The purpose of this draft is to define an information model that
describes the QoS capabilities of different devices. These capabilities
define the attributes common to the classification, conditioning,
queuing, and forwarding characteristics of network devices running
Differentiated Services QoS as well as (in the future) RSVP. 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 capabilities) 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 second draft [QCAPSCH] 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 draft is similarly paired with the draft specified in [QOSSCH],
which describes a mapping of the data in [QOSPIM] to a form suitable
for implementation in a directory that uses (L)DAP as its access
protocol. These two drafts then describe how to write QoS policy rules
that can be used to store information in directories that can be used
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
services as well as RSVP at the behavioral level. Vendors can then map
these attributes, either directly or using a proxy agent like a PIB, to
their own device-specific implementations.
This draft also concentrates on separating the concepts of state and
configuration. Configuration attributes are used to describe the
desired state of the device, whereas state attributes reflect the
current condition of the device. Both state as well as configuration
attributes are necessary in order to model and manage QoS at the device
level.
The data in this draft is influenced from the DMTF Network information
model. It is specifically not derived from the core Policy information
model. There are two reasons for this. First, this draft expresses the
fundamental QoS capabilities of a device. As such, this draft models
the mechanisms that are controlled by policy. Hence, there is a need to
separate QoS mechanisms (this draft) from their control (generic policy
draft [PCIM] augmented by the QoS Policy draft [QOSPIM]). Second, this
draft describes the general capabilities of a device. These
capabilities can be expanded to support broader policies that can
encompass not only QoS, but also security, address management, network
topology management, and routing policies, to name a few. Therefore, it
makes more sense to derive the attributes from an information model
that is already modeling these devices and services rather than
reinventing them under the umbrella of the policy information model.
Strassner, et. al. Expires September 2000 [Page 5
INTERNET-DRAFT QoS Device Info Model March, 2000
Finally, this draft considers various aggregation methods for
describing groups of devices and groups of interfaces that require a
common configuration. This approach draws on the concepts of roles that
have been discussed in the Policy Framework, DiffServ, and RAP working
groups.
A future iteration of this draft will expand the information model to
include modeling and managing the signaling characteristics of RSVP. A
separate draft ([QCAPSCH] will map the information model presented in
this draft to a form suitable for implementation in a directory that
uses (L)DAP as its access protocol.
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 combined. 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.
Regardless of what level the operands are specified at, they still need
to be specified and standardized. The Policy Framework draft ([FRAME])
discusses how these different forms of policy can be used by different
elements in a policy system.
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 takes the
first steps in identifying and standardizing a set of operands for use
in policies.
Strassner, et. al. Expires September 2000 [Page 6
INTERNET-DRAFT QoS Device Info Model March, 2000
1.2 Typical Examples of Policy Usage
Typical examples of policies described in the Policy Framework would be
implemented as low-level policies using the information model described
in this specification. For example, in the low-level policy model, a
condition represents an actual evaluation of a specified attribute in
the information model described in this specification. Therefore, a
condition such as 'If filter = HTTP' would be interpreted as a test
determining whether any HTTP filters have been specified 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. Further, this low-level policy model provides all
the same benefits that have been ascribed to policy-based management
paradigms.
Strassner, et. al. Expires September 2000 [Page 7
INTERNET-DRAFT QoS Device Info Model March, 2000
2. Approach
QoS activities in the IETF have mainly focused in two areas, Integrated
Services (IntServ) and Differentiated Services (DiffServ). This draft
initially focuses on the specification of QoS attributes and classes
for the policy management of Differentiated Services capabilities.
However, the framework defined by the structure of the classes defined
in this document is designed to cover the needs of managing policies
for signaling, such as RSVP.
2.1. Common Needs Of DiffServ and IntServ
First, we consider the common needs for IntServ and DiffServ. 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, 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 this
information model.
This draft focuses on 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.
Strassner, et. al. Expires September 2000 [Page 8
INTERNET-DRAFT QoS Device Info Model March, 2000
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 of the
network and the edges of the network. As explained in the DiffServ
Architecture document [DSARCH], 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 packet (as described
in [DSFIELD]). 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. In
addition, the standards for edges of the DiffServ network need more
detail before the edges can 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 considered in a future iteration of
this draft.
Strassner, et. al. Expires September 2000 [Page 9
INTERNET-DRAFT QoS Device Info Model March, 2000
3. Methodology
As there is a clear need to define QoS attributes from which to
construct policies, there are some very basic issues that need to be
considered. Considering these issues should help in constructing a
schema for managing the configuration of network QoS mechanisms through
the use of QoS policies.
3.1 Level of Abstraction for Expressing QoS Policies
The first issue requiring consideration is the level of abstraction at
which QoS policies should be expressed. If we consider policies as a
set of rules used to react to events and manipulate attributes or
generate new events, we realize that policy represents a continuum of
specifications that relate business goals and rules to the conditioning
of traffic done by a device or a set of devices. An example of 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.
As policies are a function of parameters (attributes) and operators
(boolean, arithmetic, relational, etc.), both need to be defined in
order to construct policies that are broadly implementable. 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, but as a whole have different conditioning
characteristics based on a number of different factors with respect to
other collections of services (e.g., Silver, Bronze, and Best Effort).
In other words, what is lacking is the set of specifications for the
set of services that make up Gold Service, and how policies are used
to control device mechanisms to implement different types of traffic
conditioning in response to each of the services that make up Gold
Service.
Strassner, et. al. Expires September 2000 [Page 10
INTERNET-DRAFT QoS Device Info Model March, 2000
We also have to define the service semantics (i.e., for Gold Service in
the above example) if we want to have uniform application of the policy
in all network devices. Any service definition would have to be
grounded in semantics like Delay, Jitter, Bandwidth, Reliability, Loss,
and over-subscription rules, just to name a few.
Finally, it can not be overstressed that policy must be thought of as a
continuum of specifications. Network administrators want to specify
policies in terms that they are familiar with (e.g., Gold Service get
lets latency and jitter than Silver Service) and donÆt necessarily want
to deal with configuring QoS capabilities at a low level (e.g.,
specifying queue configuration). However, devices need to be configured
at a significantly lower level, with much more low-level parameters
driving their configuration. The goal, then, is to use policies to
relate the 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. In addition, policies must be
specified at a device-independent level. 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.
The Policy Framework draft ([FRAME]) describes a continuum of policies
as:
- high-level policies, which express business rules
- device-independent policies, which express a common set of
configuration parameters that can be used by any device to
implement a specific type of traffic conditioning
- device-specific policies, which map the device-independent
policies into a form that is specific to a particular type of
device or set of devices
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 ss described in [QOSPIM].
Strassner, et. al. Expires September 2000 [Page 11
INTERNET-DRAFT QoS Device Info Model March, 2000
3.2 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 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:
- the modeling of a generic network service that has QoS capabilities
- the modeling of how DiffServ traffic conditioning is defined
- the modeling of how statistics are gathered to monitor DiffServ
(and other types of QoS) services
3.3 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 the 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 (queue depths, excess
capacity consumption, loss rates, and so forth).
Strassner, et. al. Expires September 2000 [Page 12
INTERNET-DRAFT QoS Device Info Model March, 2000
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 state attributes tend to be device-specific. In
contrast, a configuration attribute can be represented and applied to a
set of devices (e.g., 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). This suggests that the schema
for configuration attributes will not be exactly the same as the schema
that supports state attributes. However, there will be significant
overlap in the definition of these attributes, and significant
dependencies between the configuration and state attributes that are
used to manage a QoS service. Specifically, the configuration schema is
likely to be very general, whereas the state schema will focus on the
needs of specific devices. The intersection of these two schemata
(e.g., through a set of associations and aggregations that relates one
schema to the other) defines where it is possible to model the
configuration of QoS services that apply to one or more devices.
3.4 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.
3.5 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-specific QoS attributes be
derived from?
Strassner, et. al. Expires September 2000 [Page 13
INTERNET-DRAFT QoS Device Info Model March, 2000
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
characteristics of a networking device. Not all characteristics are
always applicable, and so this abstraction is represented by referring
to the 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 device mechanisms. Furthermore, policy is used to control
those mechanisms, not to represent them. For example, QoS services are
implemented with schedulers, classifiers, policers, and buffer
managers. 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 different mechanisms than are
used by QoS services, even though they are both implemented in the same
device. As such, QoS attributes should be part of a networking device
schema rather than a policy schema. Although a policy schema may use
QoS attributes to define policies, the policy schema really needs 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, the ultimate goal is to be able to apply policies that
control these features in network devices. Furthermore, these two
schemata must be tightly integrated in order to enable policy to
control QoS services.
3.6 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. First,
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).
The second alternative is to create multi-modal attributes that express
the same value but 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).
Strassner, et. al. Expires September 2000 [Page 14
INTERNET-DRAFT QoS Device Info Model March, 2000
The last option is to express all attributes in absolutes, but make the
operators in the policy schema 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.7 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
the 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 ([DSARCH], [DSFIELD], [AF], and [EF]).
This model assumes that there is a class that represents a set of QoS
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 in turn 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.
This document, in its current form, identifies three types of QoS
services: DiffServ, 802.1P, and IntServ. For DiffServ, it further
differentiates between AF, EF, and Precedence. This latter is meant to
be able to map between DiffServ domains and non-DiffServ domains that
only use the precedence bits in the ToS byte to communicate QoS
requirements.
This document also defines a standard set of sub-services that are used
to implement a DiffServ service. These sub-services model the concept
of a Traffic Conditioning Block (TCB, as defined in [DSMODEL]), along
with additional services that are used in conjunction with the TCB to
implement network QoS. Thus, classification, metering, marking, and
queuing are defined as sub-services of a TCB, while the buffer manager
and scheduler are defined to support the TCB.
Finally, various statistics are proposed to properly instrument QoS
services. Some of these are defined by the DiffServ MIB [DSMIB] and are
reproduced here; others are new and instrument different aspects of
traffic conditioning that are not yet covered by the DiffServ MIB.
Strassner, et. al. Expires September 2000 [Page 15
INTERNET-DRAFT QoS Device Info Model March, 2000
4. The Class Hierarchy
The following sections describe the class hierarchy of the information
model for modeling QoS capabilities at the device level. Section 4.1
defines the structure of the class hierarchy, and section 4.2 defines
the classes and their attributes that make up this class hierarchy.
4.1 Difference Between Inheritance and Relationship Hierarchies
This draft defines two different class hierarchies that are not
necessarily rooted from the same point in the overall schema. However,
it is intended that these two hierarchies be used together to control
and administer devices that are running Differentiated and Integrated
Services. Therefore, we propose one class hierarchy to manage the state
of these services, and a different (but related) class hierarchy to
manage the configuration of these services. Both of these hierarchies
are influenced from the Common Information Model, and are compatible
with the Directory Enabled Networks (DEN) effort.
These two hierarchies are integrated through the use of associations
and aggregations.
4.1.1 Associations
An association is a means of representing a dependency relationship
between two or 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
object-oriented abilities that other non-association classes have. For
example, it can contain properties and methods, and inheritance can be
used to refine the semantics of an association such that it represents
a more specialized type of dependency. Since this has proven to be a
very useful abstraction, this implementation of associations 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 ternary 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.
Strassner, et. al. Expires September 2000 [Page 16
INTERNET-DRAFT QoS Device Info Model March, 2000
4.1.2. Aggregations
An aggregation is a strong form of an association, which usually
represents a "whole-part" relationship. For example, CIM uses an
aggregation to represent the containment relationship between a system
and the components that make up the system.
An aggregate object is treated as an atomic unit, even though an
aggregate object is comprised of 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.
Aggregations therefore 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.
4.2. The Structure of the Class Hierarchy
The following sections discuss the class hierarchies that will be used
to model the state and the configuration inheritance hierarchies.
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 1 in the next
page. 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 September 2000 [Page 17
INTERNET-DRAFT QoS Device Info Model March, 2000
|
+--ManagedSystemElement (defined in [CIMCORE])
| |
| +--LogicalElement (defined in [CIMCORE])
| | |
| | +--Service (defined in [CIMCORE])
| | | |
| | | +--NetworkService (defined in [CIMNET])
| | | | |
| | | | +--ForwardingService (defined in [CIMNET])
| | | | | |
| | | | | +--TrafficConditioningBlock
| | | | | | |
| | | | | | +--ClassifierService
| | | | | | |
| | | | | | +--MeterService
| | | | | | | |
| | | | | | | +--AverageRateMeter
| | | | | | | |
| | | | | | | +--EWMAMeter
| | | | | | | |
| | | | | | | +--TokenBucketMeter
| | | | | | |
| | | | | | +--MarkerService
| | | | | | |
| | | | | | +--DropperService
| | | | | | | |
| | | | | | | +--HeadTailDropper
| | | | | | | |
| | | | | | | +--RedDropper
| | | | | | | | |
| | | | | | | | +--WeightedRedDropper
| | | | | | | | | |
| | | | | | | | | +--PercentageDropper
| | | | | | |
| | | | | | +--QueuingService
| | | | | | |
| | | | | | +--SchedulingService
| | | | | | | |
| | | | | | | +--PriorityScheduler
| | | | | | | |
| | | | | | | +--BandwidthScheduler
| | | | | | | |
| | | | | | | +--WeightedPacketScheduler
| | | | | | |
(continued on following page)
Strassner, et. al. Expires September 2000 [Page 18
INTERNET-DRAFT QoS Device Info Model March, 2000
(continued from previous page, first four are repeated for convenience)
+--ManagedSystemElement (defined in [CIMCORE])
| |
| +--LogicalElement (defined in [CIMCORE])
| | |
| | +--Service (defined in [CIMCORE])
| | | |
| | | +--NetworkService (defined in [CIMNET])
| | | | |
| | | | +--ForwardingService
| | | | | |
| | | | | +--PacketSchedulingService
| | | | | | |
| | | | | | +--PriorityScheduler
| | | | | | | |
| | | | | | | +--PriorityBandwidthScheduler
| | | | | | |
| | | | | | +--BandwidthScheduler
| | | | | | |
| | | | | | +--RoundRobinPacketScheduler
| | | | | | | |
| | | | | | | +--WeightedRoundRobinPacketScheduler
| | | | |
| | | | +--BufferManagerService
| | | | |
| | | | +--QoSService
| | | | | |
| | | | | +--DiffServService
| | | | | | |
| | | | | | +--AFService
| | | | | | |
| | | | | | +--EFService
| | | | | | |
| | | | | | +--PrecedenceService
| | | | | | |
| | | | | +--8021PService
| | |
| | +--ServiceTime
| | |
| | +--FilterEntry
| | |
| | +--FilterList
| | |
(continued on following page)
Strassner, et. al. Expires September 2000 [Page 19
INTERNET-DRAFT QoS Device Info Model March, 2000
(continued from previous page, first four are repeated for convenience)
+--StatisticalInformation (defined in [CIMCORE])
| |
| +--ServiceStatisticalInformation (defined in [CIMCORE])
| | |
| | +--FilterListStatistics
| | |
| | +--QoSStatistics
| | |
| | +--DiffServStatistics
| | | |
| | | +--PrecedenceStatistics
| | |
| | +--TCBStatistics
| | |
| | +--ClassifierStatistics
| | |
| | +--MeterStatistics
| | |
| | +--MarkerStatistics
| | |
| | +--DropperStatistics
| | |
| | +--QueuingStatistics
| | |
| | +--BufferManagerStatistics
| | |
| | +--SchedulerStatistics
Figure 1. Inheritance 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.
Strassner, et. al. Expires September 2000 [Page 20
INTERNET-DRAFT QoS Device Info Model March, 2000
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 capabilities of network devices.
This information is derived from the Networks Common Model. Only new
classes that are 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 ManagedSystemElement
This is an abstract class that is defined in the Core Model of CIM.
This 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.2 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. This is the base class
for all components of a managed System that represent abstract system
components, 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.3 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. This is the base class for
all objects that contain the information necessary to represent and
manage the functionality provided by a Device and/or SoftwareFeature.
Note that a Service is a general-purpose object that is used to
configure and manage the implementation of functionality. It is not the
functionality itself. Please refer to [CIM] for the full definition of
this class.
4.3.4 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. This is the base class
that serves as the root of the network service hierarchy. Network
services represent generic functions that are available from the
network that condition and/or modify one or more parameters of the
traffic being sent, such as fields in its header. Please refer to [CIM]
for the full definition of this class.
Strassner, et. al. Expires September 2000 [Page 21
INTERNET-DRAFT QoS Device Info Model March, 2000
4.3.5 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. This class
represents the forwarding of network traffic by receiving data from one
or more communication sources and sending that data via other
communication sources.
NAME ForwardingService
DESCRIPTION A concrete class for describing the common
characteristics of network forwarding services
that examine traffic and either forward it or
drop it. The dropping is done through an
active queue management mechanism
(e.g., RED [RED]).
DERIVED FROM NetworkService
TYPE Structural
PROPERTIES ProtocolType
OtherProtocolType
4.3.6 The Class TrafficConditioningBlock
This is a new concrete class that is defined in this model. The concept
of a Traffic Conditioning Block (TCB) is defined in [DSMODEL]. It
represents a logical entity in the data forwarding path that is made up
of a set of lower-level entities interconnected in such a way as to
perform a specific set of traffic conditioning functions on an incoming
traffic stream. These conditioning functions consist of a combination
of a classifier, meter, queue, and an action. Note that this is modeled
as a set of sub-services that are managed and configured together that
operate on the traffic.
Its definition is as follows:
NAME TrafficConditioningBlock
DESCRIPTION A concrete class for describing how an input
traffic stream is conditioned using a common
set of building blocks that provide different
types of forwarding services (e.g., metering
and dropping).
DERIVED FROM ForwardingService
TYPE Structural
PROPERTIES Enabled
ID
4.3.6.1 The Attribute Enabled
This is a boolean attribute that, if TRUE, signifies that forwarding
can be done on this port.
Strassner, et. al. Expires September 2000 [Page 22
INTERNET-DRAFT QoS Device Info Model March, 2000
4.3.6.2 The Attribute ID
This is a string attribute that can be used to contain unique
information that helps disambiguate this ForwardingService from other
ForwardingServices on the same device.
4.3.7 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 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).
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 one or more filters to sort an input stream into one or
more output streams, where each output stream is the result of matching
a particular filter (or not matching any filter). This is modeled as a
sub-service that is part of a TCB that aggregates one or more filters,
defines a set of traffic classes that represent its outputs, and has
the ability to invoke another TCB element.
Its definition is as follows:
NAME ClassifierService
DESCRIPTION A concrete class for describing how an input
traffic stream is sorted into multiple output
streams using one or more filters.
DERIVED FROM TrafficConditioningBlock
TYPE Structural
PROPERTIES ClassifierType, OtherClassifierType,
IsIngress, Status, TrafficClasses
4.3.7.1 The Attribute ClassifierType
This is an enumerated 16-bit unsigned integer that is used to define
the specific type of classifier that this instance is. 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; 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.
Strassner, et. al. Expires September 2000 [Page 23
INTERNET-DRAFT QoS Device Info Model March, 2000
4.3.7.2 The Attribute 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.7.3 The Attribute IsIngress
This is a boolean attribute that, if TRUE, means that this filter is
used to sort input traffic.
4.3.7.4 The Attribute Status
This is an enumerated 16-bit unsigned integer that describes the status
of this classifier. Possible values include:
0 û Unknown; 1 û OK; 2 û Error; 3 û Degraded; 4 û Failed;
5 û Starting; 6 û Stopping; 7 û Ready
The values are interpreted as follows:
1 (OK) represents a running device that is fully operational
2 (Error) represents a generic error; the device is stopped
3 (Degraded) means that the device is functioning, but in a
degraded way.
4 (Failed) means that the device has failed and is stopped.
5 (Starting) means that the device is being initialized, but is not
yet ready to operate.
6 (Stopping) means that the device is in the process of stopping
operation
7 (Ready) indicates that the device is stopped and is ready to be
started.
4.3.7.5 The Attribute TrafficClasses
This is an array of strings. Each string represents a different traffic
class that the input stream can be sorted into.
4.3.8 MeterService
This is a new concrete class that is 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. Non-conforming packets may be further
conditioned (e.g., dropped or queued) by routing the packet to an
appropriate conditioning element. Please see [DSMODEL] for more
information on metering.
Strassner, et. al. Expires September 2000 [Page 24
INTERNET-DRAFT QoS Device Info Model March, 2000
This class is the base class for defining different types of meters. As
such, it contains common properties that all meter subclasses share.
This is modeled as a sub-service that is part of a TCB that has the
ability to invoke another TCB element for conforming traffic and a
different TCB element for non-conforming traffic.
Its definition is as follows:
NAME MeterService
DESCRIPTION A concrete class for describing the monitoring
of traffic with respect to a pre-established
traffic profile.
DERIVED FROM TrafficConditioningBlock
TYPE Structural
PROPERTIES MeterType
ConformanceLevels
OtherMeterConformance
FailAction
SucceedAction
4.3.8.1 The Attribute 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
enumerations are:
1: Other
2: AverageRateMeter
3: EWMAMeter
4: TokenBucketMeter
4.3.8.2 The Attribute ConformanceLevels
This attribute is an enumerated 16-bit unsigned integer. This contains
the names of different conformance levels. Recommended values are:
1: Other
2: Fully conformant
3: Partially conformant
4: Non-conformant
4.3.8.3 The Attribute OtherMeterConformance
This string attribute is used in conjunction with the ConformanceLevels
attribute. When the value of ConformanceLevels is 1 (e.g., Other),
then the name of the conformance level for this meter is defined in
this attribute.
Strassner, et. al. Expires September 2000 [Page 25
INTERNET-DRAFT QoS Device Info Model March, 2000
4.3.8.4 The Attribute FailAction
This attribute is a string that contains the name of the TCB element to
send non-conforming traffic to.
4.3.8.5 The Attribute SucceedAction
This attribute is a string that contains the name of the TCB element to
send conforming traffic to.
4.3.9 The Class AverageRateMeter
This is a new concrete class that is defined in this model. It is a
subclass of the MeterService class. This class is used to describe a
simple meter, called an Average Rate Meter, which 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].
This is modeled as a sub-service that is part of a TCB that has the
ability to invoke another TCB element for conforming traffic and a
different TCB element for non-conforming traffic.
Its definition is as follows:
NAME AverageRateMeter
DESCRIPTION A concrete class for describing admitted
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
TYPE Structural
PROPERTIES Rate
Interval
4.3.9.1 The Attribute Rate
This is a 32-bit real number that defines the rate that is used to
determine whether admitted packets are in conformance or not.
4.3.9.2 The Attribute Interval
This is a 32-bit real number that defines the time period over which
the average measurement should be taken.
Strassner, et. al. Expires September 2000 [Page 26
INTERNET-DRAFT QoS Device Info Model March, 2000
4.3.10 The Class EWMAMeter
This is a new concrete class that is defined in this model. It is a
subclass of the MeterService class. This class 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.
This is modeled as a sub-service that is part of a TCB that has the
ability to invoke another TCB element for conforming traffic and a
different TCB element for non-conforming traffic.
Its definition is as follows:
NAME EWMAMeter
DESCRIPTION A concrete class for 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
Delta
Interval
Gain
4.3.10.1 The Attribute 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.
4.3.10.2 The Attribute Delta
This attribute is a 32-bit real number that defines the sampling
interval used to measure the arrival rate in bytes. This rate is
averaged over a pre-defined sampling interval (defined in the Interval
attribute) and checked against the AverageRate attribute. All packets
whose computed average arrival rate is less than the AverageRate are
deemed conforming.
4.3.10.3 The Attribute Interval
This attribute is a 32-bit real number that defines the average arrival
rate of packets.
Strassner, et. al. Expires September 2000 [Page 27
INTERNET-DRAFT QoS Device Info Model March, 2000
4.3.10.4 The Attribute Gain
This attribute is a 32-bit real number that defines the time constant
over which to measure the incoming packet rate.
4.3.11 The Class TokenBucketMeter
This is a new concrete class that is defined in this model. This class
defines a general token bucket meter. A simple token bucket usually has
two parameters, an average token rate and a burst size. This type of
meter compares the packet arrival rate to the average token rate.
Packets of length L bytes are defined to be conforming if L tokens are
available at the time of the arrival of the packet. Packets are allowed
to exceed the average rate in bursts up to the burst size. Packets that
exceed the burst size are deemed non-conforming. Such meters have two
conformance levels û conforming and non-conforming.
This class also defines an excess burst size, which enables it to have
three conformance levels û 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
burst size but are less than the excess burst size are deemed partially
conforming. Operation of this meter is described in [DSMODEL].
This is modeled as a sub-service that is part of a TCB that has the
ability to invoke another TCB element for conforming traffic and a
different TCB element for non-conforming traffic.
Its definition is as follows:
NAME TokenBucketMeter
DESCRIPTION A concrete class for 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.11.1 The Attribute AverageRate
This attribute is a 32-bit real number that is used to define the
committed rate of the meter.
Strassner, et. al. Expires September 2000 [Page 28
INTERNET-DRAFT QoS Device Info Model March, 2000
4.3.11.2 The Attribute PeakRate
This attribute is a 32-bit real number that is used to define the peak
rate of the meter.
4.3.11.3 The Attribute BurstSize
This attribute is a 32-bit real number that is used to define the
maximum number of tokens available for the committed rate.
4.3.11.4 The Attribute ExcessBurstSize
This attribute is a 32-bit real number that is used to define the
maximum number of tokens available for the peak rate.
4.3.12 The Class MarkerService
This is a new concrete class that is defined in this model. This class
describes markers, which are functional elements that are use to
(re)set a particular field in a packet header. Markers may act either
on unmarked packets or re-mark previously marked packets. Markers are
usually invoked as a result of a preceding classifier match. Operation
of various types of markers is described in [DSMODEL].
This is modeled as a sub-service that is part of a TCB that has the
ability to mark traffic and then invoke another TCB element for further
processing of the traffic.
Its definition is as follows:
NAME MarkerService
DESCRIPTION A concrete class for defining the value of a
field in a packet that is used to control the
conditioning that the packet receives.
DERIVED FROM TrafficConditioningBlock
TYPE Structural
PROPERTIES CanRemark
RemarkType
RemarkValue
4.3.12.1 The Attribute CanRemark
This is a boolean attribute that, when TRUE, signifies that this Marker
can remark the field value specified in the RemarkType attribute with
the value specified in the RemarkValue attribute. Otherwise, if the
field value is filled in, then NO remarking will be done.
Strassner, et. al. Expires September 2000 [Page 29
INTERNET-DRAFT QoS Device Info Model March, 2000
4.3.12.2 The Attribute 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.12.3 The Attribute 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.13 The Class DropperService
This is a new concrete class that is defined in this model. This class
represents the ability to drop network traffic. This is the base class
for different types of droppers. These droppers are distinguished by
the algorithm that they use to drop traffic. Please see [DSMODEL] for
more information about a dropper.
This is modeled as a sub-service that is part of a TCB that has the
ability to drop traffic.
Its definition is as follows:
NAME DropperService
DESCRIPTION A concrete base class used to describe the
common characteristics of droppers.
DERIVED FROM TrafficConditioningBlock
TYPE Structural
PROPERTIES DropperType
OtherDropperType
AlwaysDrop
MinQueueThreshold
MaxQueueThreshold
4.3.13.1 The Attribute DropperType
This is an enumerated 16-bit attribute that defines the type of dropper
that this instance is. Values include:
1: Other
2: HeadTail
3: RED
4: WRED
Strassner, et. al. Expires September 2000 [Page 30
INTERNET-DRAFT QoS Device Info Model March, 2000
4.3.13.2 The Attribute 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.13.3 The Attribute AlwaysDrop
This is a boolean attribute that, if TRUE, signifies that this Dropper
will always drop incoming packets regardless of its type.
4.3.13.4 MinQueueThreshold
This is a 32-bit unsigned integer that defines the minimum queue level.
If there are more packets than this level, then dropping of packets
will commence according to the algorithm employed by this particular
interface.
4.3.13.5 MaxQueueThreshold
This is a 32-bit attribute that defines the maximum queue level. If
there are more packets than this level, then all packets above this
level will be dropped regardless of the type of dropper used by this
particular interface.
4.3.14 The Class HeadTailDropper
This is a new concrete class that is defined in this model. This class
represents the dropping of network traffic from either the front or the
rear of the queue, depending on whether this instance is a head or a
tail dropper. Please see [DSMODEL] for more information about a
dropper.
This is modeled as a sub-service that is part of a TCB that has the
ability to drop traffic.
Its definition is as follows:
NAME HeadTailDropper
DESCRIPTION A concrete class used to describe either head
Or tail droppers.
DERIVED FROM DropperService
TYPE Structural
PROPERTIES IsTailDropper
Strassner, et. al. Expires September 2000 [Page 31
INTERNET-DRAFT QoS Device Info Model March, 2000
4.3.14.1 The Attribute IsTailDropper
This is a boolean attribute that, if TRUE, signifies that this instance
is a TailDropper. In other words, the dropper will drop packets from
the end of the queue. If this attribute is FALSE, then it is a
HeadDropper, and packets from the front of the queue will be dropped.
4.3.15 The Class REDDropper
This is a new concrete class that is defined in this model. This class
represents the dropping of network traffic using the RED algorithm as
described in, for example, [RED]. REDÆs purpose is congestion
avoidance. 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.
This is modeled as a sub-service that is part of a TCB that has the
ability to drop traffic.
Its definition is as follows:
NAME REDDropper
DESCRIPTION A concrete class used to describe dropping
using the RED algorithm (or one of its
variants).
DERIVED FROM DropperService
TYPE Structural
PROPERTIES StartProbability, StopProbability
StartPercent, StopPercent
4.3.15.1 The Attribute StartProbability
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 Attribute StopProbability
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 Attribute StartPercent
This is a 32-bit real number, and is used in conjunction with the
StopPercent attribute to define the slope of the drop probability
function which governs the rate at which packets are subject to being
dropped as a function of the queue length.
Strassner, et. al. Expires September 2000 [Page 32
INTERNET-DRAFT QoS Device Info Model March, 2000
4.3.15.4 The Attribute StopPercent
This is a 32-bit real number, and is used in conjunction with the
StartPercent attribute to define the slope of the drop probability
function which governs the rate at which packets are subject to being
dropped as a function of the queue length.
4.3.16 The Class WeightedREDDropper
This is a new concrete class that is defined in this model. This class
represents the dropping of network traffic using the weighted RED
algorithm as described in, for example, [WRED]. This modification of
the basic RED algorithm enables packets belonging to different traffic
classes to be dropped at different queue depths. This algorithm also
enable discard to be done based on different information contained in
the packetÆs header, such as IP Precedence or RSVP session parameters,
or on other factors, such as the queue depth. Please see [DSMODEL] for
more information about a dropper.
This is modeled as a sub-service that is part of a TCB that has the
ability to drop traffic.
Its definition is as follows:
NAME WeightedREDDropper
DESCRIPTION A concrete class used to describe dropping
using the weighted RED algorithm.
DERIVED FROM REDDropper
TYPE Structural
PROPERTIES DropMetric, OtherDropMetric, Weight
4.3.16.1 The Attribute DropMetric
This attribute is an enumerated 16-bit unsigned integer, and defines
the type of metric that is used to drop traffic with. Values include:
1: Other
2: IP Precedence
3: DSCP Value
4: 802.1Q Priority Value
5: RSVP Session
6: Queue Depth
4.3.16.2 The Attribute 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 to be used is defined in this attribute.
Strassner, et. al. Expires September 2000 [Page 33
INTERNET-DRAFT QoS Device Info Model March, 2000
4.3.16.3 The Attribute Weight
This is a 32-bit real number that representing the weighting factor
used to determine the weighted average queue length.
4.3.17 The Class QueuingService
This is a new concrete class that is defined in this model. This class
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.
This is modeled as a sub-service that is part of a TCB that has the
ability to queue traffic.
Its definition is as follows:
NAME QueuingService
DESCRIPTION A concrete class used to describe the ability
to queue network traffic and to specify the
characteristics for determining long-term
congestion.
DERIVED FROM TrafficConditioningBlock
TYPE Structural
PROPERTIES SmoothingWeight, Interval
4.3.17.1 The Attribute 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 queue
depth.
4.3.17.2 The Attribute Interval
This attribute is a 32-bit unsigned integer, and defines the number of
nano-seconds between each calculation. 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.
Strassner, et. al. Expires September 2000 [Page 34
INTERNET-DRAFT QoS Device Info Model March, 2000
4.3.18 The Class BufferManagementService
This is a new concrete class that is defined in this model. This class
represents the management of the buffer(s) used by the Queuing Service.
In implementations where there are multiple buffer sizes, an instance
of BufferManagementService 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 BuffersPartOf association. Please
see [DSMODEL] for more information about queuing functionality.
This is modeled as a separate service that a TCB uses, not as a sub-
service of the TCB, for managing queuing. Note that this class is
derived from NetworkService, not TrafficConditioningBlock. Its
definition is as follows:
NAME BufferManagementService
DESCRIPTION A concrete class used to represent the
buffer(s) used by the queuing service.
DERIVED FROM NetworkService
TYPE Structural
PROPERTIES BufferSize, TotalBuffers, AvailableBuffers,
SharedBuffers
4.3.18.1 The Attribute BufferSize
This attribute is a 16-bit unsigned integer, and that specifies the
number of bytes in each buffer.
4.3.18.2 The Attribute TotalBuffers
This attribute is a 32-bit unsigned integer, and defines the total
number of buffers in the buffer pool described by this instance of the
BufferManagementService class.
4.3.18.3 The Attribute AvailableBuffers
This attribute is a 32-bit unsigned integer, and represents the number
of buffers in the pool that are currently not allocated to any instance
of a queuing service. Buffers allocated to a queuing service could
either be in use (containing packet data), or allocated to a queue
pending the arrival of new packet data.
4.3.18.4 The Attribute SharedBuffers
This attribute is a 32-bit unsigned integer, and indicates the number
of buffers in the buffer pool that are been simultaneously being
allocated to multiple instances of queuing services.
Strassner, et. al. Expires September 2000 [Page 35
INTERNET-DRAFT QoS Device Info Model March, 2000
4.3.19 The Class PacketSchedulingService
This is a new concrete class that is defined in this model. This class
represents the scheduling service, which is a process that determines
whether a queued packet should be removed from the queue and sent to
the output interface or not. 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 the scheduler is
servicing. This allows implementations that support different
schedulers for different queues to be supported. Please see [DSMODEL]
for more information about a scheduler.
This is modeled as a sibling service to the TCB. Both are derived from
a common root, ForwardingService.
Its 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
PROPERTIES SchedulerType, OtherSchedulerType,
GiveExcessCapacity
4.3.19.1 The Attribute SchedulerType
This attribute is an enumerated 16-bit unsigned integer, and defines
the type of scheduler that this instance is. Values include:
1: Other
2: Priority
3: Bandwidth
4: Priority Bandwidth
5: Round Robin Packet
6: Weighted Round Robin Packet
4.3.19.2 The Attribute 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.
Strassner, et. al. Expires September 2000 [Page 36
INTERNET-DRAFT QoS Device Info Model March, 2000
4.3.19.3 The Attribute GiveExcessCapacity
This is a boolean attribute, and determines if the scheduling resources
from the current queue is available to other queues/scheduler
instances. Note that when this attribute is true, the association
ExcessCapacity scheduler is used to describe how excess resources are
allocated.
4.3.20 The Class PriorityScheduler
This is a new concrete class that is defined in this model. This class
represents a simple priority scheduler, which is a process that
schedules arriving packets into different priority queues. Please see
[DSMODEL] for more information about a scheduler.
This is modeled as a specialization of the PacketSchedulingService,
which is a sibling service to the TCB. Both PacketSchedulingService and
TCB are derived from a common root, ForwardingService. Its definition
is as follows:
NAME PriorityScheduler
DESCRIPTION A concrete class used to represent a simple
priority scheduling service.
DERIVED FROM PacketSchedulingService
TYPE Structural
PROPERTIES None
4.3.21 The Class PriorityBandwidthScheduler
This is a new concrete class that is defined in this model. 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. Please see [DSMODEL] for more information about a
scheduler.
This is modeled as a specialization of the PacketSchedulingService,
which is a sibling service to the TCB. Both PacketSchedulingService and
TCB are derived from a common root, ForwardingService. Its definition
is as follows:
NAME PriorityBandwidthScheduler
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 PriorityScheduler
TYPE Structural
PROPERTIES BandwidthAllocation, BurstsAllowed,
BurstAllocation
Strassner, et. al. Expires September 2000 [Page 37
INTERNET-DRAFT QoS Device Info Model March, 2000
4.3.21.1 The Attribute 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 Attribute 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 attribute
is allowed.
4.3.21.3 The Attribute 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
attribute. If the maximum actual bandwidth allocation were to be
measured, it would be the sum of the BurstAllocation and the Bandwidth
allocation attributes.
4.3.22 The Class BandwidthScheduler
This is a new concrete class that is defined in this model. This class
represents a bandwidth scheduler, which is a process that reserves a
portion of the bandwidth of a link for each selected traffic type. This
is modeled as a specialization of the PacketSchedulingService, which is
a sibling service to the TCB. Both PacketSchedulingService and TCB are
derived from a common root, ForwardingService. Its definition is as
follows:
NAME BandwidthScheduler
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.22.1 The Attribute BandwidthAllocation
This attribute is a 32-bit unsigned integer, and defines the number of
bytes that can be delivered from a queue each cycle.
Strassner, et. al. Expires September 2000 [Page 38
INTERNET-DRAFT QoS Device Info Model March, 2000
4.3.22.2 The Attribute 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 attribute
is allowed.
4.3.22.3 The Attribute 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
attribute. If the maximum actual bandwidth allocation were to be
measured, it would be the sum of the BurstAllocation and the Bandwidth
allocation attributes.
4.3.22.4 The Attribute 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.22.5 The Attribute 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. 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.23 The Class RoundRobinPacketScheduler
This is a new concrete class that is defined in this model. This class
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. This is modeled as a specialization of the
PacketSchedulingService, which is a sibling service to the TCB. Both
PacketSchedulingService and TCB are derived from a common root,
ForwardingService. Its definition is as follows:
NAME RoundRobinPacketScheduler
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
Strassner, et. al. Expires September 2000 [Page 39
INTERNET-DRAFT QoS Device Info Model March, 2000
4.3.24 The Class WeightedRoundRobinPacketScheduler
This is a new concrete class that is defined in this model. This class
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. This is modeled as a specialization of the
PacketSchedulingService, which is a sibling service to the TCB. Both
PacketSchedulingService and TCB are derived from a common root,
ForwardingService. Its definition is as follows:
NAME WeightedRoundRobinPacketScheduler
DESCRIPTION A concrete class used to represent a weighted
packet scheduling service.
DERIVED FROM RoundRobinPacketScheduler
TYPE Structural
PROPERTIES WeightingFactor, Priority
4.3.24.1 The Attribute 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.24.2 The Attribute 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 this
condition. However, in instances where this behavior is not necessary
or undesirable, this attribute may be left unspecified.
4.3.25 The Class QoSService
This is a new concrete class that is defined in this model. This class
represents the ability to conceptualize a QoS service as a set of
coordinated sub-services. This enables the network administrator to map
business rules to the network, and the network designer to engineer the
network such that it can provide different functions for different
traffic streams.
This class defines a set of attributes that describe how to build TCBs
and other sub-services that it needs for building higher-level QoS
services, as well as relationships for defining the structure of
various QoS services and sub-services.
Strassner, et. al. Expires September 2000 [Page 40
INTERNET-DRAFT QoS Device Info Model March, 2000
For example, Gold Service may represent 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 traffic conditioning characteristics for different types of
flows. It will direct the specific type of TCB(s) and action elements
to be used in order to implement this service. Its 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 AllowClassificationService,
AllowMarkingService, AllowDroppingService,
AllowMeteringService, AllowQueuingService,
AllowSchedulingService, AllowSignalingService
4.3.25.1 The Attribute AllowClassificationService
This is a boolean attribute that, if TRUE, enables a classification
sub-service to be enabled for this QoS service.
4.3.25.2 The Attribute AllowMarkingService
This is a boolean attribute that, if TRUE, enables a marking sub-
service to be enabled for this QoS service.
4.3.25.3 The Attribute AllowDroppingService
This is a boolean attribute that, if TRUE, enables a dropping sub-
service to be enabled for this QoS service.
4.3.25.4 The Attribute AllowMeteringService
This is a boolean attribute that, if TRUE, enables a metering sub-
service to be enabled for this QoS service.
Strassner, et. al. Expires September 2000 [Page 41
INTERNET-DRAFT QoS Device Info Model March, 2000
4.3.25.5 The Attribute AllowQueuingService
This is a boolean attribute that, if TRUE, enables a queuing sub-
service to be enabled for this QoS service.
4.3.25.6 The Attribute AllowSchedulingService
This is a boolean attribute that, if TRUE, enables a scheduling sub-
service to be enabled for this QoS service.
4.3.25.7 The Attribute AllowSignalingService
This is a boolean attribute that, if TRUE, enables a signaling sub-
service to be enabled for this QoS service.
4.3.26 The Class DiffService
This is a new concrete class that is defined in this model. This class
represents using standard or custom DiffServ services to implement a
(higher-level) QoS service. Note that the DiffServ service may be only
one of a set of coordinated sub-services that together implement a
higher-level QoS service.
The DiffServ service is modeled as 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). Its definition is as follows:
NAME DiffServService
DESCRIPTION A concrete class used to represent a DiffServ
service or set of DiffServ services.
DERIVED FROM QoSService
TYPE Structural
PROPERTIES DSCP
4.3.26.1 The Attribute DSCP
This attribute is an unsigned 8-bit integer. The DSCP attribute defines
the Differentiated Services Code Point that this link uses to represent
various types of differentiated services through device-specific
configuration commands.
Strassner, et. al. Expires September 2000 [Page 42
INTERNET-DRAFT QoS Device Info Model March, 2000
4.3.27 The Class AFService
This is a new concrete class that is defined in this model. This class
represents a specialization to the general concept of forwarding
network traffic by adding specific semantics that characterize the
operation of the Assured Forwarding Service RFC [AF].
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 service as well as to lower-level sub-
services (e.g., classification, metering, dropping, queuing, and
others). Its 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
4.3.27.1 The Attribute ClassNumber
This attribute is an 8-bit unsigned integer that defines the number of
classes that this AF implementation uses.
4.3.27.2 The Attribute DropperNumber
This attribute is an 8-bit unsigned integer that defines the number of
drop precedences that this AF implementation uses.
4.3.28 The Class EFService
This is a new concrete class that is defined in this model. This class
represents a specialization to the general concept of forwarding
network traffic by adding specific semantics that characterize the
operation of the Expedited Forwarding Service RFC [EF].
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 service as well as to lower-level sub-
services (e.g., classification, metering, dropping, queuing, and
others). Its definition is as follows:
Strassner, et. al. Expires September 2000 [Page 43
INTERNET-DRAFT QoS Device Info Model March, 2000
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.29 The Class PrecedenceService
This is a new concrete class that is defined in this model. This class
represents a specialization to the general concept of forwarding
network traffic by adding specific semantics that define how traffic is
forwarded based on the value of their ToS byte.
This class is used to enable DiffServ domains and non-DiffServ domains
to exchange traffic. It represents the mapping between implementations
that do not support DiffServ, and instead use IP Precedence, to be
mapped to implementations that do support DiffServ, which use DSCPs.
The PrecedenceService 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). Its 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.29.1 The Attribute PrecedenceValue
This attribute is an 8-bit unsigned integer that defines the notion of
precedence for different types of traffic. See [DIFFSERV] for more
information on the definition, backward compatibility with the ToS byte
of IPv4 traffic, and use of this attribute.
Strassner, et. al. Expires September 2000 [Page 44
INTERNET-DRAFT QoS Device Info Model March, 2000
4.3.30 The Class 8021PService
This is a new concrete class that is defined in this model. This class
represents a specialization to 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 domains and domains that support
802.1P only to exchange traffic. It represents the mapping between
implementations that only support 802.1P priority marking to be mapped
to implementations that do support DiffServ, which use DSCPs.
The 8021PService class is modeled as 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). Its 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.30.1 The Attribute PriorityValue
This attribute is an 8-bit unsigned integer that defines the notion of
priority as specified in 802.1P implementations.
4.4 Relationships Defined in the State Portion of the Model
This section will define the relationships described in the previous
section. These relationships are implemented as classes (that can have
attributes) in the Information Model.
<to be supplied>
Strassner, et. al. Expires September 2000 [Page 45
INTERNET-DRAFT QoS Device Info Model March, 2000
4.5 Classes Defined in the Configuration Portion of the Model
<to be supplied>
4.6 Relationships Defined in the Configuration Portion of the Model
This section will define the relationships described in the previous
section. These relationships are implemented as classes (that can have
attributes) in the Information Model.
<to be supplied>
Strassner, et. al. Expires September 2000 [Page 46
INTERNET-DRAFT QoS Device Info Model March, 2000
5. Mapping to Example Policies
This section will define some simple use cases that demonstrate how
these classes and attributes can be expressed and used to create
policies. In order to express these attributes in a meaningful way,
they have to be bound to a router or an interface on a router. This
requires the introduction of two additional concepts that can flexibly
group the set of devices and interfaces.
The first concept is a means for binding a particular policy to a set
of devices that execute or act on the policy. To support this
capability, we will use the two weak relationships, PolicyGroupInSystem
and PolicyRuleInSystem, that are part of the Policy Core Information
Model. These relationships define the device or set of devices that
this policy is applicable for.
The second concept is a means for binding an attribute to a specific
interface or set of interfaces. This binding, called a Role, takes the
form of a qualifier preceding the instance name. Roles are described in
[PCIM].
So let's consider the following condition:
Customer1.ReliableService.ConsumedBandwidth > 1500
The qualifier "Customer1" is a Role that refers to a specific interface
of one or more devices. The DiffServ class, or queue (e.g., AF2,
precedence 6, or EF) is represented in the directory with a unique
instance with a unique name. In this example, ReliableService is the
instance name for an AFService class using the DSCPs for AF2.
ConsumedBandwidth is an attribute containing the current bandwidth rate
being sent on specified DiffServ class (queue) of the specified
interface. Hence, the condition reads:
If Customer1 is receiving more then 1500 Kb of AF2 traffic, then....
However, the concept of Roles has additional benefits because we can
also express a single policy that can be applied to a set of interfaces
simultaneously. Let's consider the following sample action:
CoreInterfaces.LowDelayConfig.MaxDelay = 20
In this particular case, we are qualifying this action to only apply to
the interfaces as specified by the CoreInterfaces role. In this case we
are assuming that this is the set of interfaces in a device
participating in the core of the DiffServ domain.
Strassner, et. al. Expires September 2000 [Page 47
INTERNET-DRAFT QoS Device Info Model March, 2000
Further, LowDelayConfig is an instance of some class that is used to
specify the configuration of the EF service. As mentioned earlier,
configuration classes are used to request a change in the configuration
of device or service while state classes are used to model the actual
state of the device or service. So, this action expresses the changing
of the upper bound on the maximum delay that will be tolerated for this
service on each sending interface to the core. As a side note, the
intent of the attribute MaxDelay is to provide a simple way of
expressing an upper bound on the number of packets that can be queued
up while avoiding implementation details for where or how packets are
queued or scheduled.
6. 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. However, the information in
this draft explicitly makes use of the security measures recommended in
the policy architecture defined by the Policy Framework working group.
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 (such as
PEPs and PDPs) 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 [IPSEC] 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.
7. Acknowledgments
The authors wish to thank the participants of the Policy Framework
working group for their many helpful comments and suggestions.
8. References
[TERMS] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", Internet RFC 2119, March 1997.
[PFCORE] B. Moore, E. Ellesson, J. Strassner, Policy Framework
Core Information Model, Internet Draft,
draft-ietf-policy-core-info-model-01.txt
Strassner, et. al. Expires September 2000 [Page 48
INTERNET-DRAFT QoS Device Info Model March, 2000
[PFSCHEMA] J. Strassner, E. Ellesson, B. Moore, Policy Framework
LDAP Core Schema, Internet Draft,
draft-ietf-policy-core-schema-05.txt
[QOSPIM] Y. Snir, Y. Ramberg, J. Strassner, R. Cohen, QoS Policy
Information Model, Internet draft,
draft-ietf-policy-qos-info-model-00.txt, March 2000
[QOSSCH] Y. Snir, Y. Ramberg, J. Strassner, R. Cohen, QoS Policy
Information Schema, Internet Draft,
draft-itef-policy-qos-schema-00.txt
[FRAME] M. Stevens, W. Weiss, H. Mahon, B. Moore, J. Strassner,
G. Waters, A. Westerinen, J. Wheeler, Internet Draft
Policy Framework, draft-ietf-policy-framework-00.txt
[DSARCH] D. Black, S. Blake, M. Carlson, E. Davies, Z. Whang,
W. Weiss, "An Architecture for Differentiated Services",
RFC2475, December 1998
[DSFIELD] K. Nichols, S. Blake, F. Baker, and D. Black,
"Definition of the Differentiated Services Field
(DS Byte) in the IPv4 and IPv6 Headers",
RFC2474, December 1998
[DSMODEL] Y. Bernet, A. Smith, S. Blake, A Conceptual Model for
DiffServ Routers, Internet Draft,
draft-ietf-diffserv-model-01.txt
[DSMIB] F. Baker, Differentiated Services MIB, Internet Draft,
draft-ietf-diffserv-mib-00.txt, June 1999
[PIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn,
A. Smith, Quality of Service Policy Information Base,
Internet Draft draft-mfine-cops-pib-01.txt, June 1999
[AF] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured
Forwarding PHB Group", RFC2597, June 1999
[EF] V. Jacobson, K. Nichols, K. Poduri, "An Expedited
Forwarding PHB", RFC2598, June 1999
[RAPFRAME] R. Yavatkar, D. Pendarakis, R. Guerin, "A Framework for
Policy-based Admission Control", Internet Draft,
<draft-ietf-rap-framework-01.txt>, May 1998
[CIM] CIM Specification and CIM Schemata are available at:
http://www.dmtf.org/spec/cims.html
[IPSEC] R. Atkinson, "Security Architecture for the Internet
Protocol", RFC1825, Aug. 1995.
[RED] See http://www-nrg.ee.lbl.gov/floyd/red.html
Strassner, et. al. Expires September 2000 [Page 49
INTERNET-DRAFT QoS Device Info Model March, 2000
9. Authors' Addresses
John Strassner
Cisco Systems, Building 15
170 West Tasman Drive
San Jose, CA 95134
Phone: +1-408-527-1069
Fax: +1-408-527-2477
E-mail: johns@cisco.com
Walter Weiss
Lucent Technologies
300 Baker Ave.
Concord, MA. 01742
Phone: +1-978-287-9130
Fax: +1-978-287-9050
E-mail: wweiss@lucent.com
David Durham
Intel
2111 NE 25th Avenue
Hillsboro, OR 97124
Phone: 503.264.6232
David_Durham@mail.intel.com
Andrea Westerinen
SNIA
E-mail: andreawest@mindspring.com
10. Full Copyright Statement
Copyright (C) The Internet Society (1999). 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.
Strassner, et. al. Expires September 2000 [Page 50
INTERNET-DRAFT QoS Device Info Model March, 2000
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 September 2000 [Page 51]
| PAFTECH AB 2003-2026 | 2026-04-23 17:20:53 |