ION/IPng Working Groups W. Weiss (Lucent)
INTERNET-DRAFT J. Strassner (Cisco)
A. Westerinen (Microsoft)
June 1999
Terminology for describing network policy and services
Specification
<draft-weiss-policy-device-qos-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 attributes common to the forwarding characteristics of
Differentiated Services QoS and RSVP. Once this information model is
defined, then a separate draft can be written to refine the core
information model defined in the Policy Framework working group to
model policies that control the configuration of DS-capable network
devices. This approach enables the definition of policies that can be
used to define Services for DiffServ-capable devices and networks.
The approach taken enables a common set of attributes to be defined
that can be used to model Differentiated Services QoS classes at the
Weiss & Co Expires in six months [Page 1]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
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
actual state of the device. Both state as well as configuration
attributes are necessary in order to model and manage QoS at the
device level.
In addition, this draft derives the QoS schema from the core Networks
schema defined in the DMTF rather than the core Policy schema. In
order 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, it makes more sense to derive the
attributes from a schema that is already modeling these devices and
services rather than reinventing them under the umbrella of the
policy schema.
Finally, this draft considers various aggregation methods for
describing groups of devices and groups of interfaces that require a
common configuration.
A future iteration of this draft will expand the information model to
include modeling and managing the signaling characteristics of RSVP.
A separate draft will map the information model presented in this
draft to a form suitable for implementation in a directory that uses
LDAP as its access protocol.
Weiss & Co Expires in six months [Page 2]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
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
2. Approach
2.1 Common Needs Of DiffServ and RSVP
2.2 Specific Needs of DiffServ
2.3 Specific Needs of RSVP
3. Methodology
3.1 Level of Abstraction for Expressing QoS Policies
3.2 Level of Abstraction for Defining QoS Attributes and Classes
3.3 Characterization of QoS Attributes
3.4 Identifying Common Shared Policies
3.5 QoS Schema Derivation
3.6 Attribute Representation
4. The Class Hierarchy
4.1 Structure of the Class Hierarchy
4.2 Class and Attribute Definitions
4.2.1 ManagedSystemElement
4.2.2 LogicalElement
4.2.3 Service
4.2.4 NetworkService
4.2.5 ForwardingService
4.2.6 DiffServService
4.2.6.1 The Attribute ConsumedBandwidth
4.2.6.1 The Attribute ConsumedPackets
4.2.6.1 The Attribute CurrentBandwidth
4.2.6.1 The Attribute CurrentDelay
4.2.6.1 The Attribute LostPackets
4.2.7 AFService
4.2.7.1 The Attribute AssignedBandwidth
4.2.7.2 The Attribute MaxDelay
4.2.7.3 The Attribute SmoothingInterval
4.2.7.4 The Relationship AFDropPrecedenceServices
4.2.8 AFEdgeService
4.2.9 EFService
4.2.9.1 The Attribute DSCP
4.2.9.2 The Attribute MaxAssignedBandwidth
4.2.9.3 The Attribute MaxDelay
4.2.9.4 The Relationship EFDropPrecedenceServices
Weiss & Co Expires in six months [Page 3]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
4.2.10 EFEdgeService
4.2.11 PrecedenceService
4.2.11.1 The Attribute ToS
4.2.12 IntServService
4.2.13 DropPrecedenceService
4.2.13.1 The Attribute DSCP
4.2.13.2 The Attribute InitialLossLevelStart
4.2.13.3 The Attribute InitialLossLevelStop
4.2.13.4 The Attribute FullLossLevelStart
4.2.13.5 The Attribute FullLossLevelStop
4.2.14 Configuration
4.2.15 BehaviorConfiguration
4.2.16 AFConfiguration
4.2.16.1 The Attribute AssignedBandwidth
4.2.16.2 The Attribute MaxDelay
4.2.16.3 The Attribute SmoothingInterval
4.2.16.4 The Relationship AFConfigDropPrecedenceServices
4.2.17 AFEdgeConfiguration
4.2.18 AFRoleConfiguration
4.2.19 AFVendorConfiguration
4.2.19.1 The Multi-valued Attribute Constraint
4.2.19.2 The Attribute ConstraintEncoding
4.2.20 EFConfiguration
4.2.20.1 The Attribute DSCP
4.2.20.2 The Attribute MaxAssignedBandwidth
4.2.20.3 The Attribute MaxDelay
4.2.20.4 The Relationship EFConfigDropPrecedenceServices
4.2.21 EFEdgeConfiguration
4.2.22 EFRoleConfiguration
4.2.23 EFVendorConfiguration
4.2.23.1 The Multi-valued Attribute Constraint
4.2.23.2 The Attribute ConstraintEncoding
4.2.24 IntServConfiguration
4.2.25 DropPrecedenceConfiguration
4.2.26 PrecedenceConfiguration
4.2.26.1 The Attribute ToS
5. Mapping to Example Policies
6. Security Considerations
7. Acknowledgments
8. References
9. Author's Addresses
10. Full Copyright Statement
Weiss & Co Expires in six months [Page 4]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
1. Introduction
Policy conditions and actions have two principle components: operands
and operators. Operands can be constants or variables. You can't
construct a policy without specifying what operands you want to exam-
ine and what operands you want to change. Operands can be high level
like Joe (a user) or Gold (a service). Operands can also be low
level like IP Address or a queue's bandwidth allocation. Irrespec-
tive of what level the operands are specified at, they still need to
be specified and standardized.
The second component of policy conditions and actions is a set of
operators. Operators can express relationships (greater then, in the
set, boolean OR, etc.) or assignements. Together, operators and
operands can express a variety of conditions and actions:
If Bob is an Engineer...
If the Src 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 are 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.
Weiss & Co Expires in six months [Page 5]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
2. Approach
QoS activities in the IETF have mainly focused in two areas:
Integrated Services and Differentiated Services. This draft initially
focuses on the specification of QoS attributes and classes for the
policy management of Differentiated Services capabilities.
2.1. Common Needs Of DiffServ and RSVP
First we consider the common needs for RSVP and DiffServ. RSVP 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 RSVP
is the management of the signaling protocol (e.g., PATH and RESV
messages). This component processes reservation requests, manages
bandwidth, outsources decision making to policy servers, and
interacts with Routing Table manager. We will take RSVP into
consideration when defining the schema structure. As this draft
initially focuses on the forwarding engine, elements of RSVP
applicable to the forwarding engine will be considered in the
structure of the schema.
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 and policy construction in general. Hence, RSVP will
not be considered in any detail in this iteration of the draft.
DiffServ operates exclusively in the forwarding engine. It has all
the same components of the RSVP forwarding engine with two major
differences. First, DiffServ performs classification based solely on
the DSCP field while RSVP examines a subset of a standard flow's
addressing 5-tuple. There are special cases in DiffServ where the
addressing 5-tuple 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 RSVP and DiffServ is that the effects
of RSVP on the forwarding engine are more dynamic because each newly
admitted RSVP reservation requires a reconfiguration of the
forwarding engine. In contrast, DiffServ requires far fewer changes
to the forwarding engine after the PHBs have been configured.
The approach advocated by the authors for the creation of policies is
to first identify the attributes with which policies are to be
constructed. These attributes are the parameters to expressions that
Weiss & Co Expires in six months [Page 6]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
are necessary to construct policies. There is also a parallel desire
to define the operators, relations, precedence constructs necessary
to construct the conditions and actions proposed by the core policy
schema. These efforts are beyond the scope of this document. However,
this aspect of the policy schema will be addressed in a subsequent
document.
2.1. Specific Needs Of DiffServ
DiffServ-specific rules can focus on two particular areas: the core
of the network and the edges of the network. 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 billing have to be considered. In addition,
the standards for edges of the DiffServ network need more detail
before the edges can be incorporated in the policy model. Therefore,
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 sematics of edge devices, these attributes will
also be added to the QoS schema.
2.1. Specific Needs Of RSVP
This first iteration of this document will focus exclusively on the
forwarding aspects of network QoS. Therefore, while the forwarding
aspects of RSVP will be considered, the management of the RSVP
signaling protocol will not be considered. This will be considered in
a future iteration of this draft.
Weiss & Co Expires in six months [Page 7]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
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 to construct the
proper schema for QoS attributes as well as a general Policy schema.
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
rules used to react to events and manipulate attributes or generate
new events, this concept can be applied as broadly as a business goal
and as specifically as an interaction within a device. An example of
business level policy might be: from 1:00 pm PST to 7:00 am EST sell
off 40% of 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 to the rules 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.
In contrast, if you start with a business policy like "Bob gets Gold
Service," that is not enough. We also have to define the service
semantics if we want to have uniform application of the policy in the
network devices. Any service definition would have to be grounded in
semantics like Delay, Jitter, Bandwidth, Reliability, Loss, Billing,
and over-subscription rules, just to name a few. Getting a written
agreement to the service semantics of Gold Service would not only be
extremely painful given the broad number of possible combinations,
but it would also limit the number of business policies available to
network administrators.
3.2 Level of Abstraction for Defining QoS Attributes and Classes
We therefore propose that the Policy Framework Working Group first
focus on those policies that define the Services for DiffServ capable
devices and networks. This means that we will need to standardize the
Weiss & Co Expires in six months [Page 8]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
attributes that are needed to support policies at the services level.
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). Another example could be the criteria for allowing
over-subscription of a service and the consequences (notify billing
agent or terminate session if network characteristics change). This
has the benefit of maximizing the flexibility that network
administrators have in defining new services. In addition, once the
policies for the services are defined, it is relatively easy for
network administrators to construct policies that define business
goals on top of the policies that define the service goals.
As mentioned above, the one obstacle in creating service-oriented
policies is the issue of supporting diverse implementations of QoS.
The solution is to define the QoS attributes at the behavioral level.
For DiffServ, this means that we must define the attributes that
represent the characteristics of the DiffServ PHBs. Just as it is up
to vendors to map PHBs to individual implementations, it is up to
these same vendors to map the attributes necessary to monitor and
manage the PHB to the specific vendor's implementation of the
behavior. This mapping can either be accommodated by a proxy agent
like a PIB, or it can be supported directly in the device.
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. State attributes describe the actual state of the
device. Configuration attributes include desired or proposed
thresholds, bandwidth allocations, and classification characteristics
(more rules...). State attributes include 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).
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 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 the same as the schema that
Weiss & Co Expires in six months [Page 9]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
supports state attributes.
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 in the DMTF to define devices, services,
users, groups, and collections of devices 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 Schema Derivation
The question of contexts also begs the question of what core model
QoS attributes should be derived from. Current thinking is that QoS
is part of the policy model. However, QoS is fundamentally a set of
characteristics of a networking device. It is supported 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). As such,
we argue that 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.). However, this does not preclude the Policy
Framework working group from standardizing the QoS schema. 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.
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 ...).
Weiss & Co Expires in six months [Page 10]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
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. 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., LDAP). 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.
Weiss & Co Expires in six months [Page 11]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
4. The Class Hierarchy
The following sections describe the class hierarchy of the
information model for modeling QoS 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 Structure of the Class Hierarchy
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 class hierarchy
to manage the configuration of these services. Both of these
hierarchies are derived from the Common Information Model, and are
compatible with the Directory Enabled Networks (DEN) effort.
Weiss & Co Expires in six months [Page 12]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
The structure of the Class Hierarchy for managing the state of
Differentiated and Integrated Services is as follows:
|
+--ManagedSystemElement
| |
| +--LogicalElement
| | |
| | +--Service
| | | |
| | | +--NetworkService
| | | | |
| | | | +--ForwardingService
| | | | | |
| | | | | +--DiffServService
| | | | | | |
| | | | | | +--AFService
| | | | | | | |
| | | | | | | +--AFEdgeService
| | | | | | |
| | | | | | +--EFService
| | | | | | | |
| | | | | | | +--EFEdgeService
| | | | | | |
| | | | | | +--PrecedenceService
| | | | | |
| | | | | +--IntServService
| | | | | |
| | | | | +--DropPrecedenceService
Weiss & Co Expires in six months [Page 13]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
The structure of the Class Hierarchy for managing the configuration
of Differentiated and Integrated Services is as follows:
|
+--Configuration
| |
| +--BehaviorConfiguration
| | |
| | +--AFConfiguration
| | | |
| | | +--AFEdgeConfiguration
| | | | |
| | | | +--AFRoleConfiguration
| | | | |
| | | | +--AFVendorConfiguration
| | |
| | +--EFConfiguration
| | | |
| | | +--EFEdgeConfiguration
| | | | |
| | | | +--EFRoleConfiguration
| | | | |
| | | | +--EFVendorConfiguration
| | |
| | +--IntServConfiguration
| | |
| | +--DropPrecedenceConfiguration
| | |
| | +--PrecedenceConfiguration
4.2 Class and Attribute Definitions
4.2.1 ManagedSystemElement
This is an abstract class that is defined in the Core Model of CIM.
This is the base class for the System Element hierarchy. Any
distinguishable component of a System is a candidate for inclusion in
this class, 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.2.2 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
Weiss & Co Expires in six months [Page 14]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
in the form of Logical Devices and Services. Please refer to [CIM]
for the full definition of this class.
4.2.3 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.2.4 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 configure and/or modify the traffic being sent. Please
refer to [CIM] for the full definition of this class.
4.2.5 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. Please refer to [CIM] for the full definition
of this class.
4.2.6 DiffServService
This is a concrete class that is a proposed addition to the Network
Common Model of CIM. It is a subclass of the ForwardingService class.
This class represents a specialization of the general concept of
forwarding network traffic by adding specific semantics that
characterize the operation of Differentiated Services.
The attributes defined below all have the semantics of a counter that
is being reset every second. The class definition is as follows:
Weiss & Co Expires in six months [Page 15]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
NAME DiffServService
DESCRIPTION A concrete class for describing the common
characteristics of differentiated services
that are used to affect traffic forwarding.
DERIVED FROM ForwardingService
TYPE Structural
PROPERTIES ConsumedBandwidth
ConsumedPackets
CurrentBandwidth
CurrentDelay
LostPackets
4.2.6.1 The Attribute ConsumedBandwidth
The ConsumedBandwidth attribute defines the total bandwidth that has
been consumed during the past second, including lost packets.
NAME ConsumedBandwidth
DESCRIPTION Total bandwidth consumed during the last second,
in Kbits/second
SYNTAX Integer
4.2.6.2 The Attribute ConsumedPackets
The ConsumedPackets attribute defines the total number of packets
that have been consumed during the past second, including lost
packets.
NAME ConsumedPackets
DESCRIPTION Total number of packets consumed during the last
second, in packets/second
SYNTAX Integer
4.2.6.3 The Attribute CurrentBandwidth
The CurrentBandwidth attribute defines the instantaneous value of the
current bandwidth available for this link.
NAME CurrentBandwidth
DESCRIPTION Instantaneous bandwidth currently available in this
link, in Kbits/Second
SYNTAX Integer
4.2.6.4 The Attribute CurrentDelay
The CurrentDelay attribute defines the instantaneous value of the
current delay for this link.
Weiss & Co Expires in six months [Page 16]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
NAME CurrentDelay
DESCRIPTION Instantaneous delay in this link, in Kbits/sec
SYNTAX Integer
4.2.6.5 The Attribute LostPackets
The LostPackets attribute defines the total number of packets that
have been lost during the last second on this link.
NAME LostPackets
DESCRIPTION Total number of packets lost during the last second
SYNTAX Integer
4.2.7 AFService
This is a concrete class that is a proposed addition to the Network
Common Model of CIM. It is a subclass of the DiffServService class.
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 defined
in Differentiated Services [AF].
The first two attributes defined below have the semantics of a
counter that is being reset every second. The class definition is as
follows:
NAME AFService
DESCRIPTION A concrete class for describing the common
characteristics of differentiated services
that are used to affect traffic forwarding
using the AF PHB Group.
DERIVED FROM DiffServService
TYPE Structural
PROPERTIES AssignedBandwidth
MaxDelay
SmoothingInterval
RELATIONSHIPS AFDropPrecedenceServices
4.2.7.1 The Attribute AssignedBandwidth
The AssignedBandwidth attribute defines the bandwidth that has been
assigned to this link through device-specific configuration commands.
NAME AssignedBandwidth
DESCRIPTION Assigned bandwidth to this link in Kbits/second
SYNTAX Integer
Weiss & Co Expires in six months [Page 17]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
4.2.7.2 The Attribute MaxDelay
The MaxDelay attribute defines the total delay through this link.
NAME MaxDelay
DESCRIPTION Total delay in this link, in microseconds
SYNTAX Integer
4.2.7.3 The Attribute SmoothingInterval
The SmoothingInterval is a constant used to calculate the level of
congestion in the link, so that instantaneous bursts can be properly
filtered over time.
NAME SmoothingInterval
DESCRIPTION Constant used to calculate the level of congestion in
the link
SYNTAX Integer
4.2.7.4 The Relationship AFDropPrecedenceServices
The AFDropPrecedenceServices relationship is an aggregation that
makes explicit the dependency between an instance of an AF service
class and the instances of the drop precedence classes that it uses.
For example, [AF] defines four service classes, each with three drop
precedences. However, the semantics are that the AF class can not be
completely specified until the drop precedences are specified. This
is an example of a "whole-part" relationship, where the antecedent
(the AFService instance) is not "complete" until its constituent
parts (the instances of the DropPrecedence class) are defined and
"attached" to it.
The multiplicity of this relationship is one-or-more (on the
AFService side) to zero-or-more (on the DropPrecedence side). This
means that a particular AFService instance can use zero or more
DropPrecedence instances, and that multiple AFService instances can
use the same DropPrecedence instance.
4.2.8 AFEdgeService
This is a concrete class that is a proposed addition to the Network
Common Model of CIM. It is a subclass of the AFService class. 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 defined
in Differentiated Services [AF] that are specific to edge devices (as
opposed to distribution and core devices).
Weiss & Co Expires in six months [Page 18]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
The class definition is as follows:
NAME AFEdgeService
DESCRIPTION A concrete class for describing the common
characteristics of differentiated services
that are used to affect traffic forwarding
using the AF PHB Group, specifically for
edge devices.
DERIVED FROM AFService
TYPE Structural
PROPERTIES <to be defined>
4.2.9 EFService
This is a concrete class that is a proposed addition to the Network
Common Model of CIM. It is a subclass of the DiffServService class.
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
defined in Differentiated Services [EF].
The first two attributes defined below have the semantics of a
counter that is being reset every second. The class definition is as
follows:
NAME EFService
DESCRIPTION A concrete class for describing the common
characteristics of differentiated services
that are used to affect traffic forwarding
using the EF PHB Group.
DERIVED FROM DiffServService
TYPE Structural
PROPERTIES DSCP
MaxAssignedBandwidth
MaxDelay
RELATIONSHIPS EFDropPrecedenceServices
4.2.9.1 The Attribute DSCP
The DSCP attribute defines the Differentiated Services Code Point
that this link uses to represent the EF service through device-
specific configuration commands.
Weiss & Co Expires in six months [Page 19]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
NAME DSCP
DESCRIPTION DiffServ Code Point used to select the EF service
SYNTAX String
4.2.9.2 The Attribute MaxAssignedBandwidth
The MaxAssignedBandwidth attribute defines the maximum bandwidth that
has been assigned to this link through device-specific configuration
commands.
NAME MaxAssignedBandwidth
DESCRIPTION Maximum assigned bandwidth to this link in
Kbits/second
SYNTAX Integer
4.2.9.3 The Attribute MaxDelay
The MaxDelay attribute defines the maximum delay that this link has.
NAME MaxAssignedBandwidth
DESCRIPTION Maximum delay of this link in microseconds
SYNTAX Integer
4.2.9.4 The Relationship EFDropPrecedenceServices
The EFDropPrecedenceServices relationship is an aggregation that
makes explicit the dependency between an instance of an EF service
class and the instances of the drop precedence classes that it uses.
For example, [EF] defines a service class. However, one could define
additional EF service classes as well as assign a drop precedence to
each. If a drop precedence is assigned to an EF service class, then
the semantics are that the EF class can not be completely specified
until the drop precedence(s) are specified. This is an example of a
"whole-part" relationship, where the antecedent (the EFService
instance) is not "complete" until its constituent parts (the
instances of the DropPrecedence class) are defined and "attached" to
it.
The multiplicity of this relationship is one-or-more (on the
EFService side) to zero-or-more (on the DropPrecedence side). This
means that a particular EFService instance can use zero or more
DropPrecedence instances, and that multiple EFService instances can
use the same DropPrecedence instance. sp
4.2.10 EFEdgeService
This is a concrete class that is a proposed addition to the Network
Common Model of CIM. It is a subclass of the EFService class. This
class represents a specialization to the general concept of
Weiss & Co Expires in six months [Page 20]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
forwarding network traffic by adding specific semantics that
characterize the operation of the Expedited Forwarding Service
defined in Differentiated Services [EF] that are specific to edge
devices (as opposed to distribution and core devices).
The class definition is as follows:
NAME EFEdgeService
DESCRIPTION A concrete class for describing the common
characteristics of differentiated services
that are used to affect traffic forwarding
using the EF PHB Group, specifically for
edge devices.
DERIVED FROM EFService
TYPE Structural
PROPERTIES <to be defined>
4.2.11 PrecedenceService
This is a concrete class that is a proposed addition to the Network
Common Model of CIM. It is a subclass of the DiffServService class.
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
defined in Differentiated Services [EF] that are specific to edge
devices (as opposed to distribution and core devices).
The class definition is as follows:
NAME PrecedenceService
DESCRIPTION A concrete class for describing the common
characteristics of differentiated services
that are used to affect traffic forwarding.
This class defines the concept of traffic
precedence, so that precedence may be used in
implementing differentiated services such as
those specified in [AF] and [EF].
DERIVED FROM DiffServService
TYPE Structural
PROPERTIES ToS
4.2.11.1 The Attribute ToS
The Type of Service, or ToS, attribute, 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.
Weiss & Co Expires in six months [Page 21]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
NAME ToS
DESCRIPTION Type of Service setting, used to provide different
Priorities for different types of traffic.
SYNTAX String
4.2.12 IntServService
This is a concrete class that is a proposed addition to the Network
Common Model of CIM. It is a subclass of the ForwardingService class.
This class represents a specialization to the general concept of
forwarding network traffic as applied to the Integrated Services
model. An example of a protocol using this model is RSVP.
The class definition is as follows:
NAME IntServService
DESCRIPTION A concrete class for describing the common
characteristics of integrated services
that are used to affect traffic forwarding
when using signaling mechanisms (e.g., RSVP).
DERIVED FROM ForwardingFService
TYPE Structural
PROPERTIES <to be defined>
4.2.13 DropPrecedenceService
This is a concrete class that is a proposed addition to the Network
Common Model of CIM. It is a subclass of the ForwardingService class.
This class represents a specialization to the general concept of
forwarding network traffic that meets a particular specification, and
dropping traffic that doesn't.
The class definition is as follows:
NAME DropPrecedenceService
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 EFService
TYPE Structural
PROPERTIES DSCP
InitialLossLevelStart
InitialLossLevelStop
FullLossLevelStart
FullLossLevelStop
Weiss & Co Expires in six months [Page 22]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
4.2.13.1 The Attribute DSCP
The DSCP attribute defines the Differentiated Services Code Point
that this link uses to represent the EF service through device-
specific configuration commands.
NAME DSCP
DESCRIPTION DiffServ Code Point used to select the Drop
Precedence service
SYNTAX String
4.2.13.2 The Attribute InitialLossLevelStart
The InitialLossLevelStart attribute defines the value of the average
queue depth at which point whatever active queue management algorithm
is being used should start dropping packets. The rate of packet drop
will increase as a function of the increase of the average queue
size, until the average queue size reaches the full loss level. This
attribute is used in conjunction with the InitialLossLevelStop
attribute to define a rate at which the drop probability should
increase until the average queue size reaches the maximum threshold.
NAME InitialLossLevelStart
DESCRIPTION Initial value at which packets will be dropped
SYNTAX String
4.2.13.3 The Attribute InitialLossLevelStop
The InitialLossLevelStop attribute defines the value of the average
queue depth at which whatever active queue management algorithm is
being used should start dropping packets. It, in conjunction with the
InitialLossLevelStart attribute, define the slope of the packet
dropping function.
NAME InitialLossLevelStop
DESCRIPTION Initial value at which packets will be dropped
SYNTAX String
4.2.13.4 The Attribute FullLossLevelStart
The FullLossLevelStart attribute defines the value of the average
queue depth at which point whatever active queue management algorithm
is being used should start dropping all packets.
NAME FullLossLevelStart
DESCRIPTION Value at which all packets will be dropped
SYNTAX String
Weiss & Co Expires in six months [Page 23]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
4.2.13.5 The Attribute FullLossLevelStop
The FullLossLevelStop attribute defines the value of the average
queue depth at which point whatever active queue management algorithm
is being used should start dropping all packets.
NAME FullLossLevelStop
DESCRIPTION Value at which all packets will be dropped
SYNTAX String
4.2.14 Configuration
This is a concrete class that is defined in the Core Model of CIM. It
is a top-level class that enables the grouping of sets of parameters
(defined in, for example, Setting objects) and dependencies for one
or more ManagedSystemElements. The Configuration object represents a
certain behavior, or a desired functional state, for the
ManagedSystemElements. The desired functional state is typically
driven by external requirements such as time or location. Please
refer to [CIM] for the full definition of this class.
4.2.15 BehaviorConfiguration
This is a concrete class that is a proposed addition to the Network
Common Model of CIM. It is a subclass of the Configuration class.
This class represents specialized configuration needs that can be
used to configure the behavior of network services, such as Assured
Forwarding and Expedited Forwarding.
The class definition is as follows:
NAME BehaviorConfiguration
DESCRIPTION A concrete class for describing the common
configuration characteristics of network
services, such as Assured Forwarding and
Expedited Forwarding.
DERIVED FROM Configuration
TYPE Structural
PROPERTIES <tbd>
4.2.16 AFConfiguration
This is a concrete class that is a proposed addition to the Network
Common Model of CIM. It is a subclass of the BehaviorConfiguration
class. This class represents specialized configuration needs that can
be used to configure the behavior of the Assured Forwarding service.
The class definition is as follows:
Weiss & Co Expires in six months [Page 24]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
NAME AFConfiguration
DESCRIPTION A concrete class for describing the common
configuration characteristics of the Assured
Forwarding service.
DERIVED FROM BehaviorConfiguration
TYPE Structural
PROPERTIES AssignedBandwidth
MaxDelay
SmoothingInterval
RELATIONSHIPS AFConfigDropPrecedenceServices
4.2.16.1 The Attribute AssignedBandwidth
The AssignedBandwidth attribute defines the desired bandwidth (e.g.,
the bandwidth that will be configured for this device) to this link
through device-specific configuration commands.
NAME AssignedBandwidth
DESCRIPTION Assigned bandwidth to this link in Kbits/second
SYNTAX Integer
4.2.16.2 The Attribute MaxDelay
The MaxDelay attribute defines the desired total delay (e.g., the
delay resulting from the configuration of this device) through this
link.
NAME MaxDelay
DESCRIPTION Total delay in this link, in microseconds
SYNTAX Integer
4.2.16.3 The Attribute SmoothingInterval
The SmoothingInterval is a constant used to calculate the level of
congestion in the link, so that instantaneous bursts can be properly
filtered over time. This attribute represents the value of this
constant that will be used when the device is configured.
NAME SmoothingInterval
DESCRIPTION Constant used to calculate the level of congestion in
the link
SYNTAX Integer
4.2.16.4 The Relationship AFConfigDropPrecedenceServices
The AFConfigDropPrecedenceServices relationship is an aggregation
that makes explicit the dependency between an instance of an
AFConfiguration class and the instances of the drop precedence
Weiss & Co Expires in six months [Page 25]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
classes that it uses. For example, [AF] defines four service classes,
each with three drop precedences. However, the semantics are that the
AF class can not be completely specified until the drop precedences
are specified. This is an example of a "whole-part" relationship,
where the antecedent (the AFService instance) is not "complete" until
its constituent parts (the instances of the DropPrecedence class) are
defined and "attached" to it. This association is used to define the
initial configuration of these services.
The multiplicity of this relationship is one-or-more (on the
AFConfiguration side) to zero-or-more (on the DropPrecedence side).
This means that a particular AFConfiguration instance can use zero or
more DropPrecedence instances, and that multiple AFConfiguration
instances can use the same DropPrecedence instance.
4.2.17 AFEdgeConfiguration
This is a concrete class that is a proposed addition to the Network
Common Model of CIM. It is a subclass of the AFConfiguration class.
This class represents specialized configuration needs that can be
used to configure the behavior of the Assured Forwarding service for
edge devices.
The class definition is as follows:
NAME AFEdgeConfiguration
DESCRIPTION A concrete class for describing the common
configuration characteristics of the Assured
Forwarding service for edge devices.
DERIVED FROM AFConfiguration
TYPE Structural
PROPERTIES <tbd>
4.2.18 AFRoleConfiguration
This is a concrete class that is a proposed addition to the Network
Common Model of CIM. It is a subclass of the AFEdgeConfiguration
class. This class represents specialized configuration needs that can
be used to configure the behavior of the Assured Forwarding service
for edge devices by using roles to identify groups of devices and
groups of interfaces that are to be configured. This enforces the
semantics of managing the common configuration of a group of
interfaces and/or devices.
The class definition is as follows:
Weiss & Co Expires in six months [Page 26]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
NAME AFRoleConfiguration
DESCRIPTION A concrete class for describing the common
configuration characteristics of the Assured
Forwarding service for edge devices that are
identified by roles. Note that roles can also be
used to identify the interfaces of a device or a
group of devices.
DERIVED FROM AFEdgeConfiguration
TYPE Structural
PROPERTIES <tbd>
4.2.19 AFVendorConfiguration
This is a concrete class that is a proposed addition to the Network
Common Model of CIM. It is a subclass of the AFEdgeConfiguration
class. This class represents specialized configuration needs that can
be used to configure the behavior of the Assured Forwarding service
for edge devices on a per-vendor and per-device basis.
Vendor-specific configuration is, of course, unique to each vendor.
Therefore, a standard set of attributes can not be defined in a
specification. Instead, this class provides an array of OctetStrings
(implemented as the Constraint attribute) and a single encoding of
who the vendor is (represented by the ConstraintEncoding attribute).
The Constraint attribute provides a way for the vendor to store,
retrieve, manage, and distribute configuration commands that are
specific to the vendor identified by the (registered) OID value
contained in the ContraintEncoding attribute.
This class therefore provides a general escape mechanism for
representing common configuration policies that are specific to a
particular vendor. This enables the vendor to implement a standards-
compliant architecture that can be used to configure vendor-specific
functions. As its name suggests, this class is intended for vendor-
specific extensions. Standardized extensions are not expected to use
this class.
The class definition is as follows:
NAME AFVendorConfiguration
DESCRIPTION A concrete class for describing the common
configuration characteristics of the Assured
Forwarding service for edge devices that are
specific to a particular vendor.
DERIVED FROM AFEdgeConfiguration
TYPE Structural
PROPERTIES Constraint[]
ConstraintEncoding
Weiss & Co Expires in six months [Page 27]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
4.2.19.1. The Multi-valued Attribute Constraint
This attribute provides a general escape mechanism for representing
configuration commands controlled by policy that have not been
modeled with specific attributes. One use of this is to model
vendor-specific configuration commands.
The format of the uint8 array is left unspecified in this
definition. It is instead determined by the OID value stored in the
ConstraintEncoding attribute. Since ConstraintEncoding is single-
valued, all of the values of Constraint share the same format and
semantics.
A policy decision point can readily determine whether it supports
the values stored in an instance of Constraint by checking the OID
value from ConstraintEncoding against the set of OIDs it recognizes.
The action for the policy decision point to take in case it does not
recognize the format of this data could itself be modeled as a
policy rule, governing the behavior of the policy decision point.
The attribute definition is as follows:
NAME Constraint
DESCRIPTION Escape mechanism for representing constraints
that have not been modeled as specific
attributes. The format of the values is
identified by the OID stored in the
ConstraintEncoding attribute.
SYNTAX OctetString
4.2.19.2. The Attribute ConstraintEncoding
This attribute identifies the encoding and semantics of the
Constraint attribute values in this instance. The value of this
attribute is a single string, representing an OID which identifies
the vendor.
The attribute definition is as follows:
NAME ConstraintEncoding
DESCRIPTION An OID encoded as a string, identifying the
format and semantics for this instance's
Constraint attribute.
SYNTAX string
4.2.20 EFConfiguration
Weiss & Co Expires in six months [Page 28]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
This is a concrete class that is a proposed addition to the Network
Common Model of CIM. It is a subclass of the BehaviorConfiguration
class. This class represents specialized configuration needs that can
be used to configure the behavior of the Expedited Forwarding
service.
The class definition is as follows:
NAME EFConfiguration
DESCRIPTION A concrete class for describing the common
configuration characteristics of the Assured
Forwarding service.
DERIVED FROM BehaviorConfiguration
TYPE Structural
PROPERTIES DSCP
MaxAssignedBandwidth
MaxDelay
RELATIONSHIPS EFConfigDropPrecedenceServices
4.2.20.1 The Attribute DSCP
The DSCP attribute defines the Differentiated Services Code Point
that this link uses to represent the EF service through device-
specific configuration commands.
NAME DSCP
DESCRIPTION DiffServ Code Point used to select the EF service
SYNTAX String
4.2.20.2 The Attribute MaxAssignedBandwidth
The MaxAssignedBandwidth attribute defines the desired bandwidth
(e.g., the bandwidth that will be configured for this device) to this
link through device-specific configuration commands.
NAME MaxAssignedBandwidth
DESCRIPTION Maximum assigned bandwidth to this link in
Kbits/second
SYNTAX Integer
4.2.20.3 The Attribute MaxDelay
The MaxDelay attribute defines the desired total delay (e.g., the
delay resulting from the configuration of this device) through this
link.
Weiss & Co Expires in six months [Page 29]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
NAME MaxDelay
DESCRIPTION Total delay in this link, in microseconds
SYNTAX Integer
4.2.20.4 The Relationship EFConfigDropPrecedenceServices
The EFConfigDropPrecedenceServices relationship is an aggregation
that makes explicit the dependency between an instance of an
EFConfiguration service class and the instances of the drop
precedence classes that it uses. For example, [EF] defines a service
class. However, one could define additional EF service classes as
well as assign a drop precedence to each. If a drop precedence is
assigned to an EF service class, then the semantics are that the EF
class can not be completely specified until the drop precedence(s)
are specified. This is an example of a "whole-part" relationship,
where the antecedent (the EFService instance) is not "complete" until
its constituent parts (the instances of the DropPrecedence class) are
defined and "attached" to it.
The multiplicity of this relationship is one-or-more (on the
EFConfiguration side) to zero-or-more (on the DropPrecedence side).
This means that a particular EFConfiguration instance can use zero or
more DropPrecedence instances, and that multiple EFConfiguration
instances can use the same DropPrecedence instance.
4.2.21 EFEdgeConfiguration
This is a concrete class that is a proposed addition to the Network
Common Model of CIM. It is a subclass of the EFConfiguration class.
This class represents specialized configuration needs that can be
used to configure the behavior of the Expedited Forwarding service
for edge devices.
The class definition is as follows:
NAME EFEdgeConfiguration
DESCRIPTION A concrete class for describing the common
configuration characteristics of the Expedited
Forwarding service for edge devices.
DERIVED FROM EFConfiguration
TYPE Structural
PROPERTIES <tbd>
4.2.22 EFRoleConfiguration
This is a concrete class that is a proposed addition to the Network
Common Model of CIM. It is a subclass of the EFEdgeConfiguration
class. This class represents specialized configuration needs that can
Weiss & Co Expires in six months [Page 30]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
be used to configure the behavior of the Expedited Forwarding service
for edge devices by using roles to identify groups of devices and
groups of interfaces that are to be configured. This enforces the
semantics of managing the common configuration of a group of
interfaces and/or devices.
The class definition is as follows:
NAME EFRoleConfiguration
DESCRIPTION A concrete class for describing the common
configuration characteristics of the Expedited
Forwarding service for edge devices that are
identified by roles. Note that roles can also be
used to identify the interfaces of a device or a
group of devices.
DERIVED FROM EFEdgeConfiguration
TYPE Structural
PROPERTIES <tbd>
4.2.23 EFVendorConfiguration
This is a concrete class that is a proposed addition to the Network
Common Model of CIM. It is a subclass of the EFEdgeConfiguration
class. This class represents specialized configuration needs that can
be used to configure the behavior of the ExpeditedForwarding service
for edge devices on a per-vendor and per-device basis.
Vendor-specific configuration is, of course, unique to each vendor.
Therefore, a standard set of attributes can not be defined in a
specification. Instead, this class provides an array of OctetStrings
(implemented as the Constraint attribute) and a single encoding of
who the vendor is (represented by the ConstraintEncoding attribute).
The Constraint attribute provides a way for the vendor to store,
retrieve, manage, and distribute configuration commands that are
specific to the vendor identified by the (registered) OID value
contained in the ContraintEncoding attribute.
This class therefore provides a general escape mechanism for
representing common configuration policies that are specific to a
particular vendor. This enables the vendor to implement a standards-
compliant architecture that can be used to configure vendor-specific
functions. As its name suggests, this class is intended for vendor-
specific extensions. Standardized extensions are not expected to use
this class.
The class definition is as follows:
NAME EFVendorConfiguration
Weiss & Co Expires in six months [Page 31]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
DESCRIPTION A concrete class for describing the common
configuration characteristics of the Expedited
Forwarding service for edge devices that are
specific to a particular vendor.
DERIVED FROM EFEdgeConfiguration
TYPE Structural
PROPERTIES Constraint[]
ConstraintEncoding
4.2.23.1. The Multi-valued Attribute Constraint
This attribute provides a general escape mechanism for representing
configuration commands controlled by policy that have not been
modeled with specific attributes. One use of this is to model
vendor-specific configuration commands.
The format of the uint8 array is left unspecified in this
definition. It is instead determined by the OID value stored in the
ConstraintEncoding attribute. Since ConstraintEncoding is single-
valued, all of the values of Constraint share the same format and
semantics.
A policy decision point can readily determine whether it supports
the values stored in an instance of Constraint by checking the OID
value from ConstraintEncoding against the set of OIDs it recognizes.
The action for the policy decision point to take in case it does not
recognize the format of this data could itself be modeled as a
policy rule, governing the behavior of the policy decision point.
The attribute definition is as follows:
NAME Constraint
DESCRIPTION Escape mechanism for representing constraints
that have not been modeled as specific
attributes. The format of the values is
identified by the OID stored in the
ConstraintEncoding attribute.
SYNTAX OctetString
4.2.23.2. The Attribute ConstraintEncoding
This attribute identifies the encoding and semantics of the
Constraint attribute values in this instance. The value of this
attribute is a single string, representing an OID which identifies
the vendor.
The attribute definition is as follows:
Weiss & Co Expires in six months [Page 32]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
NAME ConstraintEncoding
DESCRIPTION An OID encoded as a string, identifying the
format and semantics for this instance's
Constraint attribute.
SYNTAX string
4.2.24 IntServConfiguration
This is a concrete class that is a proposed addition to the Network
Common Model of CIM. It is a subclass of the BehaviorConfiguration
class. This class represents specialized configuration needs that can
be used to configure the behavior of Integrated Services, such as
RSVP.
The class definition is as follows:
NAME IntServConfiguration
DESCRIPTION A concrete class for describing the common
configuration characteristics of the signaling
protocols, such as RSVP.
DERIVED FROM BehaviorConfiguration
TYPE Structural
PROPERTIES <tbd>
4.2.25 DropPrecedenceConfiguration
This is a concrete class that is a proposed addition to the Network
Common Model of CIM. It is a subclass of the BehaviorConfiguration
class. This class represents specialized configuration needs that can
be used to configure the behavior of Drop Precedence Services,
regardless of which higher-level class is using them.
The class definition is as follows:
NAME DropPrecedenceConfiguration
DESCRIPTION A concrete class for describing the common
configuration characteristics of drop precedence
services independent of what other higher-level
service uses it.
DERIVED FROM BehaviorConfiguration
TYPE Structural
PROPERTIES <tbd>
RELATIONSHIPS AFDropPrecedenceServices,
EFDropPrecedenceServices,
AFConfigDropPrecedenceServices,
EFConfigDropPrecedenceServices
Note: AFDropPrecedenceServices and EFDropPrecedenceServices are
defined previously in sections 4.2.7.4 and 4.2.9.4, respectively. The
Weiss & Co Expires in six months [Page 33]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
AFConfigDropPrecedenceServices and EFConfigDropPrecedenceServices are
defined previously in sections 4.2.16.4 and 4.2.20.4, respectively.
4.2.26 PrecedenceConfiguration
This is a concrete class that is a proposed addition to the Network
Common Model of CIM. It is a subclass of the BehaviorConfiguration
class. This class represents specialized configuration needs that can
be used to configure the behavior of Precedence Services, regardless
of which higher-level class is using them.
The class definition is as follows:
NAME PrecedenceConfiguration
DESCRIPTION A concrete class for describing the common
configuration characteristics of the signaling
protocols, such as RSVP.
DERIVED FROM BehaviorConfiguration
TYPE Structural
PROPERTIES ToS
4.2.26.1 The Attribute ToS
The Type of Service, or ToS, attribute, 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. The purpose of this
attribute is to define the configuration value for the ToS setting of
this link.
NAME ToS
DESCRIPTION Type of Service setting, used to provide different
Priorities for different types of traffic.
SYNTAX String
Weiss & Co Expires in six months [Page 34]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
5. Mapping to Example Policies
All that is left is some usage cases that demonstrate how these
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 propose a new required
attribute, called PolicyScope, listing the devices for which this
policy is applicable. This attribute should be defined in the
PolicyRule object defined in the Core Information Model. The second
concept requires 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 [TERMS].
So let's consider the following condition:
Customer1.ReliableService.ConsumedBandwidth > 1500
The qualifier "Customer1" is a Role that refers to a specific
interface of a device. The DiffServ class, or queue (e.g., AF3,
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. Further,
LowDelayConfig is an instance of the EFConfiguration class. As
mentioned earlier, configuration classes are used to request a change
in the configuration of device or service while state classes are
Weiss & Co Expires in six months [Page 35]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
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.
Weiss & Co Expires in six months [Page 36]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
7. Acknowledgments
Weiss & Co Expires in six months [Page 37]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
8. References
[TERMS] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", Internet RFC 2119, March 1997.
[DIFFARCH] D. Black, S. Blake, M. Carlson, E. Davies, Z. Whang,
W. Weiss, "An Architecture for Differentiated Services",
RFC2475, December 1998
[DIFFSERV] K. Nichols and S. Blake, "Definition of the
Differentiated Services Field (DS Byte) in the
IPv4 and IPv6 Headers", RFC2474, December 1998
[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] Floyd, S., and Jacobson, V., "Random Early Detection
gateways for Congestion Avoidance", IEEE/ACM Transactions
on Networking, Volume 1, Number 4, August 1993,
pp. 397-413.
Weiss & Co Expires in six months [Page 38]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
11. Authors' Addresses
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
John Strassner
Cisco Systems
Bldg E
190 West Tasman Drive
San Jose, CA 95134
Phone: +1-408-527-1069
Fax: +1-408-527-2477
E-mail: johns@cisco.com
Andrea Westerinen
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 425-705-2553
Email: andreawe@microsoft.com
Weiss & Co Expires in six months [Page 39]
INTERNET-DRAFT Terminology for policy and services June 25, 1999
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.
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.
Weiss & Co Expires in six months [Page 40]
2360
