Policy rules and groups can be categorised
according to purpose and intent [ID_cim], these
may not be disjunctive:
- Motivational; targeting whether or how a pol-
icy’s goal is accomplished, like configuration
and usage policies; - Configuration; giving the default configura-
tion of a managed entity; - Installation; stating what can and cannot be
installed in an entity and configuration of the
mechanisms that do the installation; - Error and event; specifying which actions to
undertake in case of certain events, e.g. fail-
ures; - Usage; controlling the selection and configu-
ration of entities based on usage data, e.g.
configuration of entities for a certain traffic
flow; - Security; verifying that the user (client) is
the one he claims to be and then accepting
or rejecting access to entities, selecting and
applying authentication mechanisms and per-
forming accounting and auditing of entities; - Service; characterising network and other
available services.
Such a categorisation determines whether the
policy is used to motivate when or how an action
occurs, or to characterise services. Service poli-
cies describe services available in the network
while usage policies give the binding of a user
(client) to the available services.
The policies can be said to represent business
goals and objectives. These goals have to be
related to implementations in the network. This
is described by an example of having an SLA at
the higher level, which has to be related to a set
of Service Level Objects (SLOs). The SLOs give
the more specific metrics.
In [ID_pterm] SLA is defined as the documented
results of a negotiation between a customer/con-
sumer and a provider of a service. It specifies
the levels of availability, serviceability, perfor-
mance, operation or other attributes of the ser-
vice. Then the Service Level Object (SLO) is
defined as a partition of an SLA giving individ-
ual metrics and operational information to
enforce and/or monitor the SLA. SLO may be
defined as part of an SLA, or as a separate docu-
ment. It is a set of parameters and their values.
The actions of enforcing and reporting moni-
tored compliance can be implemented as one
or more policies.
The Service Level Specification (SLS) is related
to specific handling of customers’ traffic flows.
It is negotiated between a customer and the
provider. For DiffServ it defines a set of parame-
ters such as DiffServ Code Points and the Per-
Hop Behaviour, profile characteristics and treat-
ment of the traffic for those Code Points. Values
are also given for these parameters. An SLS is a
combination of some technical part of an SLA (a
negotiated agreement) and its SLOs (the individ-
ual metrics and operational data to enforce).5.2 Policy Functions and Points
Two main elements are identified in the policy
control; Policy Enforcement Point (PEP) and the
Policy Decision Point (PDP), ref. [RFC2753].
These then represent the basic functions in the
policy framework:- Monitoring. The state of the network, includ-
ing characteristics of traffic load and network
resource, has to be estimated. - Decision-making. This compares the current
state of the network to a desired state de-
scribed by an application-specific policy
and decides how to achieve the desired state.
PDPs are the points where policy decisions
are made. - Enforcement. This implements a desired pol-
icy state through a set of management com-
mands; when applied to network elements,
these management commands change the con-
figuration of the device using one or more
mechanisms. These mechanisms may be ven-
dor-specific. The PEPs are the points where
the policy decisions are actually enforced. It is
assumed that policy decisions will always be
made in the PDP and implemented in the PEP.
PEP is seen as integrated in a router, while PDP
may be located in a policy server. As described
in [RFC2753] a basic interaction can begin with
a PEP receiving a notification/message that
requires a policy decision. The PEP then formats
a request and sends it to the PDP. Such a request
may contain more information elements. The
PDP returns the policy decision, possibly with
several information elements. The PEP then
enforces the policy decision, e.g. by appropri-
ately accepting or rejecting a request and setting
values for the involved mechanisms. In order to
settle the policy decision, the PDP may engage
other servers (e.g. using protocols like SNMP
and LDAP). The PEP and PDP may be located
in the same node. Furthermore, there may be
policies locally stored in the node that also have
to be checked (LPDP). An example of this is
when an access list is stored in a border router.
Then this list has to be checked in addition to