TNM. Lab.

Experiment

Case Study on
Policies in Network and System Management

Date:13/04/20

Aim -
To study policies in Network and System Management.

Theory -

Need of implementation of policies -

The management of network infrastructure in an enterprise is a complex and daunting

affair. In an era of increasing technical complexity, it is becoming difficult to find trained
personnel that can manage the new features that are introduced into the various
servers, routers and switches. The task of managing information technology resources
becomes increasingly complex as managers must take heterogeneous systems,
different networking technologies, and distributed applications into consideration.
Policies which are derived from the goals of management define the desired behaviour
of distributed heterogeneous systems and networks, and specify means to enforce this
behavior.

A policy is the combination of rules and services where rules define the criteria for
resource access and usage. A policy is formally defined as an aggregation of policy
rules. Each policy rule is composed of a set of conditions and a corresponding set of
actions. The condition defines when the policy rule is applicable. Once a policy rule is
activated, one or more actions contained by that policy rule may be executed. These
actions are associated with either meeting or not meeting the set of conditions specified
in the policy rule.

Policies are found at every level of a corporation forming a policy hierarchy, starting from
corporate level through to small business units. At all levels they specify the desired
behavior of the underlying resources. At the corporate level, policies are predominantly
subjective and guided by intuition whereas policies for network and systems
management are technology oriented. At this level, a formalization seems possible and
necessary. The existence of management platforms calls for a way to integrate the
concept of policies into standardized management architectures. Thus, the concept of
management by policies will need to be independent of different standardized
information, functional, communication, or organizational models.
Terminology -

Policies are often seen as a link between corporate management and technology
management, thus, the word ”policy” is surrounded by a vast number of other related
terms, such as strategy, goal, vision, direction, mission, process, tactic, procedure, plan,
scheme, course, and guideline, to name just a few. The policy-based technology could
relieve the suffering of managing the large computer systems and free the manager from
monitoring the equipments and systems directly and supply a systematic method for
establishing, revising, and distributing policies. Policy is a kind of criterion that aims at
determining the choice of the actions in an individual system. The criterion is long-lasting,
illustrative, and originated from the target of the management.

Merits of policies in network management -

1. When system requirement alters, it is only necessary to change or add some new
policies instead of re-coding.
2. To make the best use of the resources by flexible distribution of the resources
according to the dynamic information and the different requirements of various service
types.
3. Different users use different policies, and this is convenient for users and at the
same time makes the system more extensible and more maintainable.
4. Make the system less dependent on the system manager and make the system
more intelligent.
5. Many researchers and organizations have come to do research together on the
framework of the policies and its implementation and begin to apply it in the
management of the network and wireless network. Indeed the policy-based
management is still immature and need to make improvement.

Policy Hierarchy -

The policy hierarchy ([MACA 93]) illustrated in figure consists of six distinct levels of
policies with different degree of precision. The path from principal to procedural policies,

Policy Hierarchy
also known as ”stepwise refinement” in the field of software engineering, is said to
allow the transformation of words to the specification of code.

Functional policies are, in our opinion, the only true policies. They are the means to
implement strategies and thereby support management. They can be formalized to be
further processed by management systems. Process policies and procedural policies (the
last two in the hierarchy) characterize the design and implementation aspects of policies.
Other hierarchies exist and may be more suitable for policies if restricted to technical
aspects of the information technology. Such hierarchy levels could be based on physical
and logical levels of abstraction (e.g. networks and systems; subnets and subsystems;
devices and applications; board, ports and algorithms) but are not of concern here.

Policy and profiles -

The term ”profile” is sometimes used wrongly as a synonym for policy and one
could assume profiles can serve the same purpose as policies. However, profiles
define basic requirements for an interoperating management whereas policies specify
management goals. Hence a policy can be used to identify a set of managed objects
affected by the enforcement of the policy. A management profile defines a combination
of base standards along with a set of options and other variations in the base
standards. In essence, profiles define objects, attributes, notifications, etc. to allow a
certain degree of interoperating management (ie.compatability requirements) and
hence provide a basis for the development of uniform, internationally recognized
system tests.

Policies and their

context
 Control cycles and
policies

The second control cycle shown concerns the interaction between policies and
resources. It is of technical nature in that it can be automated and its steps of actions
can be formalized. In this technical control cycle policies act in some way on resources,
i.e. enforcement instructions are passed on to the resources. Their action is
automatically monitored and timely feedback is possible in order to reinforce or alter a
policy.

Aspects of the Policies -

A complete classification of policies is a difficult undertaking, as there are numerous

aspects to be considered. Following and extending the ideas in [SLOM 93] we use the
process of policy application (e.g. definition, authorization, activation, enforcement,
monitoring, and deactivation) to derive the following list of criteria which can be used to
characterize policies:

definition - Whenever a policy is defined there is the question of who/what is authorized to

specify the goals and who/what is obliged to carry out the necessary actions(obligation).

activation - As policies originate from management strategies they may be triggered

(activated) by a particular event occuring in a resource or externally. Hence triggers can
be for example timers, counters, gauges or other asynchronous events such as faults
or configuration changes.
enforcement - The enforcement of a policy consists of a chain of management actions
which may act on so called target objects. A policy may be simple in terms of initiating a
change in a single target object. However, complexity rises if the target objects are not
directly accessible, if appropriate objects do not exist at all, if the objects are themselves
complex in their functionality (e.g. applications as MOs), or if the enforcement is subject
to conflicting actions/policies. Target objects and hence policies can be assigned to one
or more functional areas such as accounting, performance, security management.
monitoring - To control the correct, efficient and timely activity of policies we need
indicators to monitor the policy enforcement.

deactivation - After a policy becomes obsolete, some information from the policy
may be retained for further management use, such as for accounting or security
means.

time - Time considerations are important for all of the above aspects because a policy
may be active throughout the lifecycle of its target objects or may only be activated for a
short while, e.g. at the start when a new network device goes into operation
(configuration policy). Policy enforcement instructions may need to be dispatched
repeatedly, for example whenever new devices are added to the configuration.

Requirements on a Formal Definition of Poli cies -

From the above characteristics, a policy definition seems to be very complex. For
policies which influence more than one functional area this may certainly be the case.
The following aspects form a minimum set of characteristics required to define a policy:

goal - A description of the policy’s aims.

target objects - The objects which are directly affected by the policy.

triggers - The initial cause for a policy to take on actions. These may be the same
objects or events to be monitored after the policy enforcement instructions are set
off.

policy actions - The functional aspect of a policy, i.e. what (not how!) changes or
measures are to be enforced, i.e. the policy enforcement actions/instructions. This must
include aspects of time, such as the duration of its activity or its monitoring process, or
the intervals for monitoring. The modality of the actions is an integral part of the actions.

monitor objects - These are objects which measure the suitability, timeliness and efficiency
of the policy actions in comparison to the desired goal.
 General policy based administration architecture -

Several working groups in the IETF and DMTF (Distributed Management Task Force) try to
define a standard policy framework and related protocols. In the figure below LDAP denotes
Lightweight Directory Access Protocol, COPS denotes Common Open Policy Protocol, and
CLI denotes Command Line Interface. It includes the following components:

The IETF Policy-Based Management Architecture

Policy Management Tool is the server or host where policy management software can do -

1. policy editing
2. policy presentation
3. rule translation
4. rule validation
5. global conflict resolution

An administrator uses the policy management tool to define the policies that are
to be enforced within the network. A device that can apply and execute the different
policies is known as the policy enforcement point (PEP).

Policy Information Repository is a data store for policy information. This data store may
be application specific, operating system specific, or an enterprise common repository.
For the purpose of this report, the policy information repository is a PBM application
specific directoryservice.
Policy information repository can -

1. store policy information

2. search policy information
3. retrieve policy information
4. rule locator
5. device adapter
6. state resource validation (requirements checking)
7. policy rule translation
8. policy transformation

The policy repository is used to store the policies generated by the management tool. In
order to ensure interoperability across products from different vendors, information stored
in the repository must correspond to an information model specified by the Policy
Framework Working Group. A policy enforcement point uses an intermediary known as
the policy decision point (PDP) to communicate with the repository. The PDP is
responsible for interpreting the policies stored in the repository and communicating them
to the PEP. The PEP or PDP may be in a single device or different physical device.
Different protocols are to be used for various parts of the architecture, e.g. COPS or
SNMP can be used for PDP-PEP communication. A repository could be a network
directory server accessed using LDAP. The structure of the management tool is not
defined by the IETF standards since a standard format is not needed for interoperability
between different machines.

The policy management tool and how it can leverage the power of policies to simplify the
provisioning and configuration of the different devices within the network. This
simplification of the management functions is obtained via two elements of the policy
management tool and the policy architecture, namely centralization and business level
abstractions.

Centralization - It refers to the process of defining all the device provisioning and
configuration at a single point (the management tool) rather than provisioning and
configuring each device itself. In a system with a large number of machines, the
centralization of configuration at a single node reduces the manual effort required of an
administrator. The administrator inputs the policies needed for network operation into the
management tool which populates the repository. The information in the repository is
specified in terms of the technology being deployed within the network, e.g. using terms
and concepts available for managing performance using the Differentiated Services
technology. The PDPs retrieve the policy defined in the technology-specific notation, and
convert it into the appropriate configuration of the PEP that can enforce the desired
policies.

The benefits of centralization on reducing manual tedium can easily be seen. In a network
of 1000 machines needing 10 minutes of configuration per machine, an administrator
would need to work over a week to configure the machines manually. With a policy-based
solution, the administrator needs to spend about 15 minutes populating the repository with
the appropriate policies, and the PEPs/PDPs would take care of the rest.

Business Level Abstractions - It make the job of policy administrator simpler by

defining the policies in terms of a language that is closer to the business needs of an
organization rather than in terms of the specific technology needed to deploy it. The
administrator need not be very conversant with the details of the technology that
supports the desired business needs.

The policy management tool -

The policy management tool needs to support the notion of policies specified as
business level abstractions as opposed to the policies specified as technology-level
abstractions. A generic policy management tool that will support these two levels of
policies can be constructed out of the four basic components.

The user interface is the means by which an administrator can input the business-level
policies within the network. The interface may consist of command lines or a graphical
tool that can be used by the administrator. Command lines permit programmatic
manipulation of the policy management tools.

The resource discovery component determines the topology of the network, the users,
and applications operational in the network. In order to generate the configuration for
the various devices in the network, the capabilities and topology of the network must
be known.

The policy transformation logic component is responsible for ensuring that the high-level
policies that are specified by the network administrator are mutually consistent, correct,
and feasible with the existing capacity and topology of the network. It also translates the
business- level policies into technology-level policies that can be distributed to the
different devices in the network.

The policy distributor is responsible for ensuring that the technology-level policies are
distributed to the various devices in the network. If the network devices support the IETF
policy architecture, policy distribution consists simply of writing the technology level
policies (low- level policies) to the repository. If some devices do not conform to the IETF
architecture, the distributor has to use alternatives, e.g. convert the low-level policies into
the appropriate device configuration, and configure the device over a command line
interface.

The user interface, resource discovery and the policy distributor are components that
have a relative straight-forward design. This is not to discount their importance; a good
user interface can make the difference between an unusable tool and a great tool.
However, the heart of policy management lies in the policy translation logic, as to how
the policies will be represented and how they will be managed.
The Policy Translation Logic -

The policy transformation logic module validates the information provided in the high-
level policies and transforms them into the configuration of devices in the network. The
validation process must incorporate syntactical checks as well as semantic checks. The
semantic validation of high-level policies consists of various types of checks:

1. Bounds checks: validates that values taken by an attribute in the policy specification
are within specific limits that are determined by the network administrator.

2. Relation checks: validates that the value taken by any two parameters in
the policy specification satisfy a relationship determined by the specific
technology.

3. Consistency Checks: validates that any two policies defined by the

administrator do not conflict with each other.

4. Dominance Checks: checks for “unreachable policies”, i.e. policies that are defined
by an administrator but will never become active in the network because they have
rendered ineffective by the definition of other policies.

5. Feasibility Checks: ensures that the set of policies desired by an administrator for
a network are feasible in the operating environment provided by the network.

Some of these checks can be made in a generic manner independent of the policy
discipline. The translation process and the feasibility checks depend on the policy
discipline that is being supported. However, given a suitable policy representation, it is
possible to perform the bounds, relations, consistency and dominance checks in a
discipline-independent manner.

Policy Representation -

The high-level and low-level policies required for network management can be specified in
many different ways. Among the researchers who are involved in specifying policies,
multiple approaches for policy specification have been proposed. These approaches
range from an interpretation of policies as programs to an interpretation of policies as
simple entries in a directory or database. From a human input standpoint, the best way to
specify a high-level policy would be in terms of a natural-language input. Although these
policies are very easy to specify, the current state of natural-language processing, a
special area within the field of artificial intelligence, needs to improve significantly before
such policies can be expressed in this manner. The next approach is to specify policies in
a special language that can be processed and interpreted by a computer. This maps a
policy to a piece of software that can be executed by a computer under certain conditions.
Another approach is to specify the policy using a formal specification language. When
policies are specified as a computer interpretable program, it is possible to execute them.
However, in general it is quite difficult to determine if the policies specified by two different
programs are mutually consistent. A simpler approach is to interpret the policy as a
sequence of rules, in which each rule is in the form of a simple condition-action pair (in a
“if-then-else” format). The rules are evaluated on specific triggers, such as the passage of
time or the

arrival of a new packet within the network. If a rule's condition is true, the action is
executed. A sample specification of the policy in this format would be "If the packet's
source or destination IP address belongs to the research or engineering subnet, encrypt
the packet."
Policies specified in this fashion are easier to analyze than policies specified as
full-blown computer programs or by a formal specification language.

Representing policies using "if-then-else" semantics may lead to the conclusion that
policy representations should be evaluated using an expert system or theorem-proving
approach. Although such an approach toward network policies is feasible, this may not
be the appropriate approach for the problem. For the most important problems that are
of relevance in an application of policies within the network, expert systems-based
approaches have several limitations. As an example, checking the mutual consistency
of a set of policies using the theorem-proving approach requires exponential running
time in many instances. An alternative specification of policies is to represent them
simply as entries in a table. The table consists of multiple attributes. Some of these
attributes constitute the condition part, and others constitute the action part. Different
types of tables need to be specified if the condition components or action components
of different rules vary. Such a tabular representation is rich enough to express most of
the policies that can be specified with a rule-based notation. Furthermore, it is easier to
analyze for dominance and consistency. The IETF has chosen a rule-based policy
representation in its specification. However, due to the need to store this representation
in an LDAP directory or database, this representation essentially follows the tabular
specification just described. For a variety of policy disciplines that arise in the field of
TCP/IP networks, we have been able to use such a tabular specification of policies to
capture most of the practical scenarios one may encounter.

Policy Validation Algorithms -

When we use a tabular representation for the policies, each policy discipline can be
characterized by a description of the set of tables in the policy definition for the discipline,
and the set of columns that make up each table. We refer to this description as a policy
schema. A column of a schema defines an attribute of the policy which could be a simple
(textual or numerical) attribute, a structured attribute consisting of multiple attributes (e.g.
an IP Subnet attribute consists of the simple attributes of Subnet Address and Prefix
Length), or a nested table (e.g. the table of interfaces at a computer). Different types of
validation criteria can be associated with each table and column of the attribute. The
validation criteria enable some of the checks to be performed in a very simple manner.
By associating a limit checking criteria with each column, the bounds checks can be
performed rather trivially. Similarly, the relations checks can be performed by defining a
relationship criteria associated with a table. Each row in the table is validated against the
relationship criteria. The checking for policy conflicts and dominance needs to be
performed across all of the rows that of a table. The consistency criterion is that if two
rules can both apply under some conditions, the actions to be performed must be
uniquely identified and be doable simultaneously.

Some policy disciplines -

Having provided an overview of the generic policy management, we will now

consider the policy management tool for a couple of disciplines. The two policy
disciplines that we will consider are -

1. the support of performance based service level agreements using the IP Differentiated
Services Technology.

2. The support of Enterprise Extranets using IP-sec protocol suite. For each of the policy
discipline that we want to apply the generic management architecture to, we need to do the
following tasks -

(a) define the policy schema for the business level policies

(b) define the policy schema for the technology level policies and

(c) define the discipline specific translation rules and

(d) define the nature of any discipline specific feasibility tests.

For demonstrating the examples with policy discipline, we would consider the
environment as that of an enterprise network consisting of several campus networks
connected together by means of wide area links. We would use some simple policy
schemas for both the business level and technology level policies, illustrating them in
UML. The policy management architecture can be used for many other disciplines and
in business environments such as a network services provider or an application services
provider

Conclusion -
Hence we have presented the characteristics of policies and derived a formal
definition for policies, merits of policy implementation, the policy hierarchy, aspects of
policies etc. We also presented the IETF administration architecture. The architecture
introduced is a first attempt to show how policies and a policy system may be realized
and incorporated in today’s
management architectures.