of rules to be used, the rules have to be priori-
tised (e.g. first-match, match all, priority order).The policy to apply to an entity (e.g. router) may
depend on many factors such as the characteris-
tics of the entity (e.g. protocol type used) and
the user connected. To describe the functions
attached to an entity, the term role is introduced,
[ID_fwpib].A role represents a functional characteristic or
capability of an entity (resource) to which poli-
cies are applied. Multiple roles may be assigned
to a single entity, resulting in that entity’s role
combination. A role should be thought of in a
wider sense than an entity’s attribute as the role
would impact which policy is selected for an
entity.A QoS policy domain contains groups of policy
rules. A policy rule can contain ordered lists of
conditions and actions. The conditions and
actions may be reusable objects that reside in
repositories, or they may be rule-specific embed-
ded in the rule or a combination of both. An
advantage of having reusable objects is that
many policy rules may refer to the same object.One way of thinking of a policy-controlled net-
work is to consider the network as a state
machine where policies are used to control
which state each of the entities should be in
or is allowed to be in at any given time.Policy rules may be aggregated into policy
groups, which may be nested to represent a hier-
archy of policies. Policy groups can model intri-
cate interactions between objects that may have
involved interdependencies, like application
type, user identity, interface, time of day, etc.
A policy group can be reused and managed as
a unit. A policy rule can be called a stand-alone
policy. These can be expressed as a simple state-
ment, e.g. represented by a Management Infor-
mation Base (MIB).The set of conditions in a rule specifies when the
policy rule is to be applied. The conditions can
be given as sets of individual condition state-
ments related by AND/OR. Negations can also
be used. When the set of conditions associated
with a policy rule is evaluated to TRUE, the set
of actions in the rule is executed. This may
either maintain the current state or imply a tran-
sition to another state. The order of execution
of the actions can be specified.Policy rules themselves can be prioritised, e.g. to
have an overall policy with some variations in
case of exceptions. An example is that policy a)
all traffic at an interface is placed into a certain
DiffServ class, except policy b)for packets hav-
ing IP destination address equal to xxx.xxx,
which are put into another DiffServ class. Then
policy b)has to get higher priority as the actions
associated with the two rules are incompatible.
Hence, the exception condition gets higher prior-
ity than the general condition.Figure 12 Policy classes and
relations, from [ID_cim]
PolicyConditionInPolicyRepository
PolicyRuleInSystemSystemPolicyGroup PolicyRepositoryPolicyRulePolicyConditionPolicyTimePeriodConditionPolicyActionPolicyGroupInPolicyGroupPolicyGroupInSystemPolicyRepositoryInPolicyRepositoryPolicyRuleInPolicyGroupPolicyActionInPolicyRepositoryPolicyConditionInPolicyRulePolicyRuleValidityPeriodPolicyActionInPolicyRule